Re: Use "1.7.7" for next release

On 14.04.2012 22:40, Hyrum K Wright wrote:
> On Sat, Apr 14, 2012 at 3:36 PM, Stefan Küng<tortoisesvn_at_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