On Apr 14, 2012 4:46 PM, "Stefan Küng" <tortoisesvn_at_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<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.
>
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
Received on 2012-04-14 23:46:37 CEST