On Apr 14, 2012 4:46 PM, "Stefan Küng" <tortoise...@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<tortoise...@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