You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Stefan Küng <to...@gmail.com> on 2012/04/14 22:15:24 UTC
Re: Use "1.7.7" for next release
On 14.04.2012 21:31, Blair Zajac wrote:
> On 4/14/12 12:24 PM, Konstantin Kolinko wrote:
>> 2012/4/12 Daniel Shahaf<da...@apache.org>:
>>> We released 1.6.18 today and 1.7.4 just over a month ago. There are
>>> a few useful items merged already, and STATUS has a truckload of pending
>>> changes.
>>>
>>> Shall we roll 1.7.5 in two weeks from today? If we can clear STATUS and
>>> roll next Thursday that's fine too, but I don't think we're in a hurry.
>>
>> Hi!
>>
>> I have a proposal:
>> Skip several numbers and name the next release as "1.7.7".
>>
>> Justification: to align with TortoiseSVN, which is 1.7.6 now.
>>
>> There is a lot of "Subversion exception!" threads on users@
>> where TortoiseSVN version is visible. For example [1].
>>
>> I think skipping those "already used" numbers will lessen confusion.
>
> Since Subversion is the base project, I would rather see TortoiseSVN
> change it's versioning to match ours than the other way. TortoiseSVN
> could add an additional version number after Subversion's, e.g.
> 1.7.4-tsvn1 for the first TortoiseSVN release based on 1.7.4,
> 1.7.4-tsvn2 for the second, etc.
The TSVN installer already mentions the SVN version number in its file
name, e.g.
TortoiseSVN-1.7.6.22632-x64-svn-1.7.4.msi
=========
And the last few 1.6.x releases also didn't have matching version
numbers, e.g.
TortoiseSVN-1.6.16.21511-x64-svn-1.6.17.msi
So that wasn't a problem back then.
Why is it now?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: Use "1.7.7" for next release
Posted by Mark Phippard <ma...@gmail.com>.
On Sat, Apr 14, 2012 at 5:52 PM, Stefan Küng <to...@gmail.com> wrote:
> On 14.04.2012 23:46, Greg Stein wrote:
>
>> > So I'll keep the first three version numbers the same in the future
>> for interim releases (in case I have to create one).
>> > But I guess if you want to improve the current situation, there's not
>> much I can do.
>> >
>>
>> Hyrum is suggesting we release 1.7.5, and you release 1.7.6.1. Then we
>> release 1.7.6, and tsvn goes to 1.7.6.2. Then we both bump to 1.7.7.
>
>
> Ok, but the TSVN version will have to be named 1.7.6-2, not 1.7.6.2 because
> the fourth number is the build revision. It's important that the fourth
> number keeps increasing with every version, otherwise the msi won't install
> correctly (we actually swap the third and fourth number for the msi because
> of that, otherwise nightly builds wouldn't install properly).
FWIW, I would say just do whatever you want. People will figure it
out. I do not see that this is a problem. Your downloads and about
dialog are very clear about the Subversion version.
With Subclipse we use odd/even version numbering so our current
version is 1.8.7. We have never tried to align with the Subversion
release number. That would be pointless as it would imply we can only
do releases when there are Subversion releases.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: Use "1.7.7" for next release
Posted by Stefan Küng <to...@gmail.com>.
On 14.04.2012 23:46, Greg Stein wrote:
> > So I'll keep the first three version numbers the same in the future
> for interim releases (in case I have to create one).
> > But I guess if you want to improve the current situation, there's not
> much I can do.
> >
>
> Hyrum is suggesting we release 1.7.5, and you release 1.7.6.1. Then we
> release 1.7.6, and tsvn goes to 1.7.6.2. Then we both bump to 1.7.7.
Ok, but the TSVN version will have to be named 1.7.6-2, not 1.7.6.2
because the fourth number is the build revision. It's important that the
fourth number keeps increasing with every version, otherwise the msi
won't install correctly (we actually swap the third and fourth number
for the msi because of that, otherwise nightly builds wouldn't install
properly).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: Use "1.7.7" for next release
Posted by Greg Stein <gs...@gmail.com>.
On Apr 14, 2012 4:46 PM, "Stefan Küng" <to...@gmail.com> wrote:
>
> On 14.04.2012 22:40, Hyrum K Wright wrote:
>>
>> On Sat, Apr 14, 2012 at 3:36 PM, Stefan Küng<to...@gmail.com>
wrote:
>>>
>>> On 14.04.2012 22:28, Greg Stein wrote:
>>>
>>>>>>> I have a proposal:
>>>>>>> Skip several numbers and name the next release as "1.7.7".
>>>>>>>
>>>>>>> Justification: to align with TortoiseSVN, which is 1.7.6 now.
>>>>>>>
>>>>>>> There is a lot of "Subversion exception!" threads on users@
>>>>>>> where TortoiseSVN version is visible. For example [1].
>>>>>>>
>>>>>>> I think skipping those "already used" numbers will lessen confusion.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Since Subversion is the base project, I would rather see TortoiseSVN
>>>>>> change it's versioning to match ours than the other way. TortoiseSVN
>>>>>> could add an additional version number after Subversion's, e.g.
>>>>>> 1.7.4-tsvn1 for the first TortoiseSVN release based on 1.7.4,
>>>>>> 1.7.4-tsvn2 for the second, etc.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The TSVN installer already mentions the SVN version number in its file
>>>>> name,
>>>>> e.g.
>>>>> TortoiseSVN-1.7.6.22632-x64-svn-1.7.4.msi
>>>>> =========
>>>>>
>>>>> And the last few 1.6.x releases also didn't have matching version
>>>>> numbers,
>>>>> e.g.
>>>>> TortoiseSVN-1.6.16.21511-x64-svn-1.6.17.msi
>>>>>
>>>>> So that wasn't a problem back then.
>>>>> Why is it now?
>>>>
>>>>
>>>>
>>>> Konstantin suggested we change Subversion to deal with the
>>>> discrepancy, rather than changing TSVN. People felt that was the wrong
>>>> direction of change...
>>>>
>>>> I have to say: it *does* make things a bit harder on the users@
>>>> mailing list. "What? 1.7.5 has not been released yet. Were you testing
>>>> with the unreleased tarball?! Did somebody release that tarball?"
>>>
>>>
>>>
>>> Ok, I see the problem.
>>>
>>> But what should I do? I can't name the next TSVN release 1.7.5 since the
>>> current TSVN version is already 1.7.6 - going back one version would
confuse
>>> users even more, and would also completely break the update check
function
>>> TSVN has.
>>>
>>> Suggestions?
>>
>>
>> I think the previously-mentioned suggestion to use a fourth value in
>> the version tuple is an excellent one. Just keep incrementing it
>> until you get back to parity with upstream releases.
>
>
> We already use the fourth value: that's the svn revision number of the
working copy at the time of the release build.
>
> While I can in the future just use those for 'interim' releases (i.e.,
releases that are out-of-sync with svn releases), that won't help with the
current situation. I can't go back a version.
>
> So I'll keep the first three version numbers the same in the future for
interim releases (in case I have to create one).
> But I guess if you want to improve the current situation, there's not
much I can do.
>
Hyrum is suggesting we release 1.7.5, and you release 1.7.6.1. Then we
release 1.7.6, and tsvn goes to 1.7.6.2. Then we both bump to 1.7.7.
Cheers,
-g
Re: Use "1.7.7" for next release
Posted by Stefan Küng <to...@gmail.com>.
On 14.04.2012 22:40, Hyrum K Wright wrote:
> On Sat, Apr 14, 2012 at 3:36 PM, Stefan Küng<to...@gmail.com> wrote:
>> On 14.04.2012 22:28, Greg Stein wrote:
>>
>>>>>> I have a proposal:
>>>>>> Skip several numbers and name the next release as "1.7.7".
>>>>>>
>>>>>> Justification: to align with TortoiseSVN, which is 1.7.6 now.
>>>>>>
>>>>>> There is a lot of "Subversion exception!" threads on users@
>>>>>> where TortoiseSVN version is visible. For example [1].
>>>>>>
>>>>>> I think skipping those "already used" numbers will lessen confusion.
>>>>>
>>>>>
>>>>>
>>>>> Since Subversion is the base project, I would rather see TortoiseSVN
>>>>> change it's versioning to match ours than the other way. TortoiseSVN
>>>>> could add an additional version number after Subversion's, e.g.
>>>>> 1.7.4-tsvn1 for the first TortoiseSVN release based on 1.7.4,
>>>>> 1.7.4-tsvn2 for the second, etc.
>>>>
>>>>
>>>>
>>>> The TSVN installer already mentions the SVN version number in its file
>>>> name,
>>>> e.g.
>>>> TortoiseSVN-1.7.6.22632-x64-svn-1.7.4.msi
>>>> =========
>>>>
>>>> And the last few 1.6.x releases also didn't have matching version
>>>> numbers,
>>>> e.g.
>>>> TortoiseSVN-1.6.16.21511-x64-svn-1.6.17.msi
>>>>
>>>> So that wasn't a problem back then.
>>>> Why is it now?
>>>
>>>
>>> Konstantin suggested we change Subversion to deal with the
>>> discrepancy, rather than changing TSVN. People felt that was the wrong
>>> direction of change...
>>>
>>> I have to say: it *does* make things a bit harder on the users@
>>> mailing list. "What? 1.7.5 has not been released yet. Were you testing
>>> with the unreleased tarball?! Did somebody release that tarball?"
>>
>>
>> Ok, I see the problem.
>>
>> But what should I do? I can't name the next TSVN release 1.7.5 since the
>> current TSVN version is already 1.7.6 - going back one version would confuse
>> users even more, and would also completely break the update check function
>> TSVN has.
>>
>> Suggestions?
>
> I think the previously-mentioned suggestion to use a fourth value in
> the version tuple is an excellent one. Just keep incrementing it
> until you get back to parity with upstream releases.
We already use the fourth value: that's the svn revision number of the
working copy at the time of the release build.
While I can in the future just use those for 'interim' releases (i.e.,
releases that are out-of-sync with svn releases), that won't help with
the current situation. I can't go back a version.
So I'll keep the first three version numbers the same in the future for
interim releases (in case I have to create one).
But I guess if you want to improve the current situation, there's not
much I can do.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: Use "1.7.7" for next release
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Sat, Apr 14, 2012 at 3:36 PM, Stefan Küng <to...@gmail.com> wrote:
> On 14.04.2012 22:28, Greg Stein wrote:
>
>>>>> I have a proposal:
>>>>> Skip several numbers and name the next release as "1.7.7".
>>>>>
>>>>> Justification: to align with TortoiseSVN, which is 1.7.6 now.
>>>>>
>>>>> There is a lot of "Subversion exception!" threads on users@
>>>>> where TortoiseSVN version is visible. For example [1].
>>>>>
>>>>> I think skipping those "already used" numbers will lessen confusion.
>>>>
>>>>
>>>>
>>>> Since Subversion is the base project, I would rather see TortoiseSVN
>>>> change it's versioning to match ours than the other way. TortoiseSVN
>>>> could add an additional version number after Subversion's, e.g.
>>>> 1.7.4-tsvn1 for the first TortoiseSVN release based on 1.7.4,
>>>> 1.7.4-tsvn2 for the second, etc.
>>>
>>>
>>>
>>> The TSVN installer already mentions the SVN version number in its file
>>> name,
>>> e.g.
>>> TortoiseSVN-1.7.6.22632-x64-svn-1.7.4.msi
>>> =========
>>>
>>> And the last few 1.6.x releases also didn't have matching version
>>> numbers,
>>> e.g.
>>> TortoiseSVN-1.6.16.21511-x64-svn-1.6.17.msi
>>>
>>> So that wasn't a problem back then.
>>> Why is it now?
>>
>>
>> Konstantin suggested we change Subversion to deal with the
>> discrepancy, rather than changing TSVN. People felt that was the wrong
>> direction of change...
>>
>> I have to say: it *does* make things a bit harder on the users@
>> mailing list. "What? 1.7.5 has not been released yet. Were you testing
>> with the unreleased tarball?! Did somebody release that tarball?"
>
>
> Ok, I see the problem.
>
> But what should I do? I can't name the next TSVN release 1.7.5 since the
> current TSVN version is already 1.7.6 - going back one version would confuse
> users even more, and would also completely break the update check function
> TSVN has.
>
> Suggestions?
I think the previously-mentioned suggestion to use a fourth value in
the version tuple is an excellent one. Just keep incrementing it
until you get back to parity with upstream releases.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: Use "1.7.7" for next release
Posted by Stefan Küng <to...@gmail.com>.
On 14.04.2012 22:28, Greg Stein wrote:
>>>> I have a proposal:
>>>> Skip several numbers and name the next release as "1.7.7".
>>>>
>>>> Justification: to align with TortoiseSVN, which is 1.7.6 now.
>>>>
>>>> There is a lot of "Subversion exception!" threads on users@
>>>> where TortoiseSVN version is visible. For example [1].
>>>>
>>>> I think skipping those "already used" numbers will lessen confusion.
>>>
>>>
>>> Since Subversion is the base project, I would rather see TortoiseSVN
>>> change it's versioning to match ours than the other way. TortoiseSVN
>>> could add an additional version number after Subversion's, e.g.
>>> 1.7.4-tsvn1 for the first TortoiseSVN release based on 1.7.4,
>>> 1.7.4-tsvn2 for the second, etc.
>>
>>
>> The TSVN installer already mentions the SVN version number in its file name,
>> e.g.
>> TortoiseSVN-1.7.6.22632-x64-svn-1.7.4.msi
>> =========
>>
>> And the last few 1.6.x releases also didn't have matching version numbers,
>> e.g.
>> TortoiseSVN-1.6.16.21511-x64-svn-1.6.17.msi
>>
>> So that wasn't a problem back then.
>> Why is it now?
>
> Konstantin suggested we change Subversion to deal with the
> discrepancy, rather than changing TSVN. People felt that was the wrong
> direction of change...
>
> I have to say: it *does* make things a bit harder on the users@
> mailing list. "What? 1.7.5 has not been released yet. Were you testing
> with the unreleased tarball?! Did somebody release that tarball?"
Ok, I see the problem.
But what should I do? I can't name the next TSVN release 1.7.5 since the
current TSVN version is already 1.7.6 - going back one version would
confuse users even more, and would also completely break the update
check function TSVN has.
Suggestions?
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: Use "1.7.7" for next release
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Apr 14, 2012 at 16:15, Stefan Küng <to...@gmail.com> wrote:
> On 14.04.2012 21:31, Blair Zajac wrote:
>>
>> On 4/14/12 12:24 PM, Konstantin Kolinko wrote:
>>>
>>> 2012/4/12 Daniel Shahaf<da...@apache.org>:
>>>>
>>>> We released 1.6.18 today and 1.7.4 just over a month ago. There are
>>>> a few useful items merged already, and STATUS has a truckload of pending
>>>> changes.
>>>>
>>>> Shall we roll 1.7.5 in two weeks from today? If we can clear STATUS and
>>>> roll next Thursday that's fine too, but I don't think we're in a hurry.
>>>
>>>
>>> Hi!
>>>
>>> I have a proposal:
>>> Skip several numbers and name the next release as "1.7.7".
>>>
>>> Justification: to align with TortoiseSVN, which is 1.7.6 now.
>>>
>>> There is a lot of "Subversion exception!" threads on users@
>>> where TortoiseSVN version is visible. For example [1].
>>>
>>> I think skipping those "already used" numbers will lessen confusion.
>>
>>
>> Since Subversion is the base project, I would rather see TortoiseSVN
>> change it's versioning to match ours than the other way. TortoiseSVN
>> could add an additional version number after Subversion's, e.g.
>> 1.7.4-tsvn1 for the first TortoiseSVN release based on 1.7.4,
>> 1.7.4-tsvn2 for the second, etc.
>
>
> The TSVN installer already mentions the SVN version number in its file name,
> e.g.
> TortoiseSVN-1.7.6.22632-x64-svn-1.7.4.msi
> =========
>
> And the last few 1.6.x releases also didn't have matching version numbers,
> e.g.
> TortoiseSVN-1.6.16.21511-x64-svn-1.6.17.msi
>
> So that wasn't a problem back then.
> Why is it now?
Konstantin suggested we change Subversion to deal with the
discrepancy, rather than changing TSVN. People felt that was the wrong
direction of change...
I have to say: it *does* make things a bit harder on the users@
mailing list. "What? 1.7.5 has not been released yet. Were you testing
with the unreleased tarball?! Did somebody release that tarball?"
Cheers,
-g