You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Konstantin Kolinko <kn...@gmail.com> on 2012/04/14 21:24:57 UTC
Use "1.7.7" for next release (was: Re: 1.7.5 in one/two weeks?)
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.
[1] http://markmail.org/message/p6d6ih2p2rzegpi7
Best regards,
Konstantin Kolinko
Re: Use "1.7.7" for next release (was: Re: 1.7.5 in one/two weeks?)
Posted by Greg Stein <gs...@gmail.com>.
On Apr 15, 2012 6:54 AM, "Alagazam.net Subversion" <sv...@alagazam.net> wrote:
>
> On 2012-04-15 04:15, Daniel Shahaf wrote:
>>
>> Konstantin Kolinko wrote on Sat, Apr 14, 2012 at 23:24:57 +0400:
>>>
>>> 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.
>>
>> To summarize, the next release will be called 1.7.5 and Stefan Küng will
>> change tsvn's versioning scheme to
>> "%d.%d.%d-%d" % (SVN_VER_MAJOR, SVN_VER_MINOR, SVN_VER_PATCH,
tsvn_counter++).
>>
>> Thanks for raising this (and thanks Stefan for the fix his end).
>>
>> Daniel
>
>
> My suggestion is that SVN skips 1.7.5 and 1.7.6 and call next release
1.7.7
> There's no unusual about skipping versions due to issues found in the
release process (1.610 and 1.6.14 was never released) so lets call this an
"issue" and "pull" the 1.7.5 and 1.7.6 releases.
>
> If tsvn is willing to adjust their versioning scheme so why not help them
a bit to get aligned.
The dev community has already stated that svn won't skip versions to align
with downstream packages. What about all the others? Why support just tsvn?
How many do we need to compensate for?
Tsvn can certainly use whatever numbering it wants. The underlying issue is
that it is so *close* to Subversion's that it creates confusion on the
users mailing list.
-g
Re: Use "1.7.7" for next release (was: Re: 1.7.5 in one/two weeks?)
Posted by "Alagazam.net Subversion" <sv...@alagazam.net>.
On 2012-04-15 04:15, Daniel Shahaf wrote:
> Konstantin Kolinko wrote on Sat, Apr 14, 2012 at 23:24:57 +0400:
>> 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.
> To summarize, the next release will be called 1.7.5 and Stefan Küng will
> change tsvn's versioning scheme to
> "%d.%d.%d-%d" % (SVN_VER_MAJOR, SVN_VER_MINOR, SVN_VER_PATCH, tsvn_counter++).
>
> Thanks for raising this (and thanks Stefan for the fix his end).
>
> Daniel
My suggestion is that SVN skips 1.7.5 and 1.7.6 and call next release 1.7.7
There's no unusual about skipping versions due to issues found in the
release process (1.610 and 1.6.14 was never released) so lets call this
an "issue" and "pull" the 1.7.5 and 1.7.6 releases.
If tsvn is willing to adjust their versioning scheme so why not help
them a bit to get aligned.
This is my 2c
David a.k.a. Alagazam
Re: Use "1.7.7" for next release
Posted by Blair Zajac <bl...@orcaware.com>.
On 04/15/2012 07:05 AM, Ashod Nakashian wrote:
> ----- Original Message -----
>> From: Daniel Shahaf<d....@daniel.shahaf.name>
>> To: Ashod Nakashian<as...@yahoo.com>; Stefan Küng<to...@gmail.com>; "dev@subversion.apache.org"<de...@subversion.apache.org>
>> Cc:
>> Sent: Sunday, April 15, 2012 2:06 PM
>> Subject: Re: Use "1.7.7" for next release
>>
>>
>>
>> On Sun, Apr 15, 2012, at 02:36, Ashod Nakashian wrote:
>>> And surely at 1.8.0 you'll sync back, so not only this will auto-
>>> correct, but as the third number is the "patch" number, I
>> personally
>>> care little whether or not the patch is a TSVN one or mainline SVN - I
>>> care about the major.minor, and that's perfectly matching.
>>
>> It's not auto-correcting, what if TSVN 1.8.0 links against SVN 1.8.0 and
>> then TSVN needs to make another release?
>>
>
> I meant the two project versions won't diverge indefinitely. Sure each patch can result in a mismatch (assuming TSVN continues to use the 3rd number for patches) but as long as both projects use the same major.minor numbers, they realign again at every significant release. Which is my point; patch numbers aren't all that relevant. What a user typically cares about are the major.minor version of SVN (which dictates features and compatibility etc.) and that they have the latest patch for *that* major.minor.
>
> In other words, if I'm using TSVN and I care to use version 1.7 of SVN features, I'll make sure I have the latest patch for 1.7 of TSVN. If that's 1.7.9, then that's the best that TSVN provides, regardless what the patch number of SVN stands at. If I care to know the exact SVN patch TSVN is linked against, I have ample places to look for this information. (and if I know of an SVN patch that TSVN doesn't yet provide, then I'll either wait or switch to a different 3rd party SVN product.)
Taking care of the second concern also resolves the first concern.
I've always found it a little more work than I would think is necessary
to see quickly see which version of Subversion TortoiseSVN is built on.
Not talking about a lot, but it's a minor annoyance.
Blair
Re: Use "1.7.7" for next release
Posted by Ashod Nakashian <as...@yahoo.com>.
----- Original Message -----
> From: Daniel Shahaf <d....@daniel.shahaf.name>
> To: Ashod Nakashian <as...@yahoo.com>; Stefan Küng <to...@gmail.com>; "dev@subversion.apache.org" <de...@subversion.apache.org>
> Cc:
> Sent: Sunday, April 15, 2012 2:06 PM
> Subject: Re: Use "1.7.7" for next release
>
>
>
> On Sun, Apr 15, 2012, at 02:36, Ashod Nakashian wrote:
>> And surely at 1.8.0 you'll sync back, so not only this will auto-
>> correct, but as the third number is the "patch" number, I
> personally
>> care little whether or not the patch is a TSVN one or mainline SVN - I
>> care about the major.minor, and that's perfectly matching.
>
> It's not auto-correcting, what if TSVN 1.8.0 links against SVN 1.8.0 and
> then TSVN needs to make another release?
>
I meant the two project versions won't diverge indefinitely. Sure each patch can result in a mismatch (assuming TSVN continues to use the 3rd number for patches) but as long as both projects use the same major.minor numbers, they realign again at every significant release. Which is my point; patch numbers aren't all that relevant. What a user typically cares about are the major.minor version of SVN (which dictates features and compatibility etc.) and that they have the latest patch for *that* major.minor.
In other words, if I'm using TSVN and I care to use version 1.7 of SVN features, I'll make sure I have the latest patch for 1.7 of TSVN. If that's 1.7.9, then that's the best that TSVN provides, regardless what the patch number of SVN stands at. If I care to know the exact SVN patch TSVN is linked against, I have ample places to look for this information. (and if I know of an SVN patch that TSVN doesn't yet provide, then I'll either wait or switch to a different 3rd party SVN product.)
If a different versioning scheme should prove less confusing to TSVN users (I was never confused by this issue and I'm a rather old user of both projects), then that can be adopted, but it's very reasonable that TSVN has its own patches (whether to fix their bugs or even SVN bugs/workarounds) and that can't match the patch number of SVN.
So if 100% alignment isn't possible, making SVN realign with TSVN more often won't help much. It's best to keep SVN independent of downstream projects (as many voiced) and that TSVN clearly advertises the patch number as their own without implied matching with SVN patches. That way the user's won't have an expectation that is wrong half the time (as is the case now).
-Ash
Re: Use "1.7.7" for next release
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
On Sun, Apr 15, 2012, at 02:36, Ashod Nakashian wrote:
> And surely at 1.8.0 you'll sync back, so not only this will auto-
> correct, but as the third number is the "patch" number, I personally
> care little whether or not the patch is a TSVN one or mainline SVN - I
> care about the major.minor, and that's perfectly matching.
It's not auto-correcting, what if TSVN 1.8.0 links against SVN 1.8.0 and
then TSVN needs to make another release?
Re: Use "1.7.7" for next release
Posted by Ashod Nakashian <as...@yahoo.com>.
----- Original Message -----
> From: Stefan Küng <to...@gmail.com>
> To: dev@subversion.apache.org
> Cc:
> Sent: Sunday, April 15, 2012 1:28 PM
> Subject: Re: Use "1.7.7" for next release
>
> On 15.04.2012 04:15, Daniel Shahaf wrote:
>> Konstantin Kolinko wrote on Sat, Apr 14, 2012 at 23:24:57 +0400:
>>> 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.
>>
>> To summarize, the next release will be called 1.7.5 and Stefan Küng will
>> change tsvn's versioning scheme to
>> "%d.%d.%d-%d" % (SVN_VER_MAJOR, SVN_VER_MINOR, SVN_VER_PATCH,
> tsvn_counter++).
>>
>> Thanks for raising this (and thanks Stefan for the fix his end).
>
> Ahem: as I said I can not go back a version. I can't name the next TSVN
> release 1.7.5-2 since we're already have version 1.7.6 out.
If TSVN 1.7.6 was understandably linked with SVN 1.7.4, why TSVN 1.7.7 linked with SVN 1.7.5 problematic? From where I'm standing, it's perfectly reasonable. In fact, I wouldn't expect it differently and will probably find a new versioning scheme a tad confusing (at least at first).
And surely at 1.8.0 you'll sync back, so not only this will auto-correct, but as the third number is the "patch" number, I personally care little whether or not the patch is a TSVN one or mainline SVN - I care about the major.minor, and that's perfectly matching.
Just my 2c.
-Ash
>
> After sleeping on this, I'm also quite concerned about not incrementing the
> TSVN version since this would confuse our users a lot, not to mention the
> problems we would get on our mailing list.
>
> I'll start a discussion on the TSVN dev list about this first, before I can
> make a decision.
>
> Stefan
>
> -- ___
> oo // \\ "De Chelonian Mobile"
> (_,\/ \_/ \ TortoiseSVN
> \ \_/_\_/> The coolest Interface to (Sub)Version Control
> /_/ \_\ http://tortoisesvn.net
>
AW: Use "1.7.7" for next release
Posted by Markus Schaber <m....@3s-software.com>.
Hi, Daniel,
Von: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Gesendet: Montag, 16. April 2012 10:33
> An: Markus Schaber
> Cc: Stefan Küng; dev@subversion.apache.org
> Betreff: Re: Use "1.7.7" for next release
>
> Markus Schaber wrote on Mon, Apr 16, 2012 at 08:02:26 +0000:
> > SharpSVN currently is on version 1.7004.2064, where the second number
> > of the tuple is a combination of the second and third tuple of the
> > upstream SVN number, and the third number is the sharpsvn revision /
> > build number.
> >
> > Of course, this scheme will run into problems when SVN someday
> > releases 1.7.1000, 1.65.535 or 1.66.0. :-)
>
> Obviously you should use a concatenation of two svndiff0 variable-length-
> integers for the middle number of SharpSVN's version strings.
>
> For 1.7.5 that makes 1.0117.
I guess this would make the problem appear earlier instead of later, as the parts of version numbers in windows exe and dll files are limited to unsigned 16 bit, so we might run out of number space even earlier due to the encoding overhead.
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Use "1.7.7" for next release
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Markus Schaber wrote on Mon, Apr 16, 2012 at 08:02:26 +0000:
> SharpSVN currently is on version 1.7004.2064, where the second number
> of the tuple is a combination of the second and third tuple of the
> upstream SVN number, and the third number is the sharpsvn revision /
> build number.
>
> Of course, this scheme will run into problems when SVN someday
> releases 1.7.1000, 1.65.535 or 1.66.0. :-)
Obviously you should use a concatenation of two svndiff0 variable-length-integers
for the middle number of SharpSVN's version strings.
For 1.7.5 that makes 1.0117.
AW: Use "1.7.7" for next release
Posted by Markus Schaber <m....@3s-software.com>.
Hi
Von: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> > [Version confusion between core SVN and TortoiseSVN]
> > After sleeping on this, I'm also quite concerned about not
> > incrementing the TSVN version since this would confuse our users a
> > lot, not to mention the problems we would get on our mailing list.
> >
> > I'll start a discussion on the TSVN dev list about this first, before
> > I can make a decision.
>
> FWIW: I'd be happy with any scheme that doesn't confuse people between
> TSVN's version number and SVN's version number. The specific numbering
> scheme (1.7.7.x or 2.7.x or "1.7.x/1.7.y" or something else altogether) is
> less important to me.
SharpSVN currently is on version 1.7004.2064, where the second number of the tuple is a combination of the second and third tuple of the upstream SVN number, and the third number is the sharpsvn revision / build number.
TortoiseSVN could maybe adopt a similar scheme. It can be adopted in the next build without decreasing any version number, and it also makes it obvious that an user with "SVN Version 1.7004.42" is not referring to plain svn, but some derivate.
Of course, this scheme will run into problems when SVN someday releases 1.7.1000, 1.65.535 or 1.66.0. :-)
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.schaber@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Use "1.7.7" for next release
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
On Sun, Apr 15, 2012, at 11:28, Stefan Küng wrote:
> On 15.04.2012 04:15, Daniel Shahaf wrote:
> > Konstantin Kolinko wrote on Sat, Apr 14, 2012 at 23:24:57 +0400:
> >> 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.
> >
> > To summarize, the next release will be called 1.7.5 and Stefan Küng will
> > change tsvn's versioning scheme to
> > "%d.%d.%d-%d" % (SVN_VER_MAJOR, SVN_VER_MINOR, SVN_VER_PATCH, tsvn_counter++).
> >
> > Thanks for raising this (and thanks Stefan for the fix his end).
>
> Ahem: as I said I can not go back a version. I can't name the next TSVN
> release 1.7.5-2 since we're already have version 1.7.6 out.
>
I am not concerned about what how you call the tsvn releases that
correspond to svn 1.7.5 and 1.7.6, if the ambiguity problem is solved in 1.7.7+.
Apologies if I was putting words in your mouth, I was trying to
summarize my reading of the consensus elsethread.
> After sleeping on this, I'm also quite concerned about not incrementing
> the TSVN version since this would confuse our users a lot, not to
> mention the problems we would get on our mailing list.
>
> I'll start a discussion on the TSVN dev list about this first, before I
> can make a decision.
FWIW: I'd be happy with any scheme that doesn't confuse people between
TSVN's version number and SVN's version number. The specific numbering
scheme (1.7.7.x or 2.7.x or "1.7.x/1.7.y" or something else altogether)
is less important to me.
>
> 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 Stefan Küng <to...@gmail.com>.
On 15.04.2012 04:15, Daniel Shahaf wrote:
> Konstantin Kolinko wrote on Sat, Apr 14, 2012 at 23:24:57 +0400:
>> 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.
>
> To summarize, the next release will be called 1.7.5 and Stefan Küng will
> change tsvn's versioning scheme to
> "%d.%d.%d-%d" % (SVN_VER_MAJOR, SVN_VER_MINOR, SVN_VER_PATCH, tsvn_counter++).
>
> Thanks for raising this (and thanks Stefan for the fix his end).
Ahem: as I said I can not go back a version. I can't name the next TSVN
release 1.7.5-2 since we're already have version 1.7.6 out.
After sleeping on this, I'm also quite concerned about not incrementing
the TSVN version since this would confuse our users a lot, not to
mention the problems we would get on our mailing list.
I'll start a discussion on the TSVN dev list about this first, before I
can make a decision.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Re: Use "1.7.7" for next release (was: Re: 1.7.5 in one/two weeks?)
Posted by Daniel Shahaf <da...@apache.org>.
Konstantin Kolinko wrote on Sat, Apr 14, 2012 at 23:24:57 +0400:
> 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.
To summarize, the next release will be called 1.7.5 and Stefan Küng will
change tsvn's versioning scheme to
"%d.%d.%d-%d" % (SVN_VER_MAJOR, SVN_VER_MINOR, SVN_VER_PATCH, tsvn_counter++).
Thanks for raising this (and thanks Stefan for the fix his end).
Daniel
Re: Use "1.7.7" for next release (was: Re: 1.7.5 in one/two weeks?)
Posted by Hyrum K Wright <hy...@wandisco.com>.
On Sat, Apr 14, 2012 at 2:31 PM, Blair Zajac <bl...@orcaware.com> 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.
Agreed. Adapting Subversion version numbers to accomodate arbitrary
downstream projects is a slippery slope toward madness.
It feels like there is a reporting issue, more than a version number issue.
-Hyrum
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
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
Re: Use "1.7.7" for next release
Posted by Stefan Küng <to...@gmail.com>.
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 (was: Re: 1.7.5 in one/two weeks?)
Posted by Greg Stein <gs...@gmail.com>.
On Sat, Apr 14, 2012 at 15:31, Blair Zajac <bl...@orcaware.com> 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.
Or 1.7.4.0, 1.7.4.1, 1.7.4.2 ... etc
Most Windows binaries have four components anyway, right?
Cheers,
-g
Re: Use "1.7.7" for next release (was: Re: 1.7.5 in one/two weeks?)
Posted by Blair Zajac <bl...@orcaware.com>.
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.
Blair