[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Use "1.7.7" for next release

From: Blair Zajac <blair_at_orcaware.com>
Date: Sun, 15 Apr 2012 07:38:13 -0700

On 04/15/2012 07:05 AM, Ashod Nakashian wrote:
> ----- Original Message -----
>> From: Daniel Shahaf<d.s_at_daniel.shahaf.name>
>> To: Ashod Nakashian<ashodnakashian_at_yahoo.com>; Stefan Küng<tortoisesvn_at_gmail.com>; "dev_at_subversion.apache.org"<dev_at_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.

Received on 2012-04-15 16:38:51 CEST

This is an archived mail posted to the Subversion Dev mailing list.