Stefan KÃ¼ng wrote on 13 Feb 2010 11:04:42:
> In the past, we shipped a new major release of TortoiseSVN in sync with
> the svn library. But now, the svn library won't have another major
> release for a long time, maybe not until the end of this year .
My crystal ball says October. Just for the record ;)
As this would still about 6 months away, an intermediate
TSVN release would have a lifetime in line with the
intended SVN release frequency of twice a year.
> Since there are already a lot of new features in the TSVN trunk, I'd
> like to discuss if we should ship TSVN 1.7.0 soon but still have it link
> against svn 1.6.x.
Personally, I would not release "just for the features"
if the resulting version numbering scheme causes confusion.
> Sure, most users can live without the new features in TSVN, but there
> are some changes which make it work better on Win7, and with many users
> switching to that new OS it would benefit them a lot if they had those
> adjustments/enhancements in TSVN.
IMO, that is the major point. We need to release Win7-
"fixes". Those, however, break backward compatibility
with W2K, for instance. 1.6.8 would definitely not be the
place to do something like that.
> So what do you think?
The whole version numbering issue is very sensitive.
De facto, TSVN releases are linked to SVN releases:
We will certainly continue our policy to ship TSVN with
the latest SVN libs. That means roughly a 2-month
release cycle for fixes. Updating more frequently than
that would certainly annoy users.
The other question is features. IOW, should more of
our releases be feature releases? Probably yes, and
probably at the rate SVN originally intended to release
(say, every 4 to 6 months). Again, even more frequent
feature releases might do more harm than good.
Back to numbering. 1.7.0 would probably send the
worst of signals possible:
* SVN devs may feel abandoned / left behind and
that at a point when they seem to take action towards
their own 1.7 release. Remember Greg's reaction on
your "when will wc-ng be usable?" post?
* Users will assume that TSVN 1.7 finally comes with
the SVN 1.7 features and will be disappointed
("obviously, SVN is stuck. Time to change").
* Users will be confused in the beginning and be
annoyed later on. ("what is the matching tool set
to install? I hate that. They obviously lost focus.
Time to change").
2.0.0 is not warranted, yet. A version linked against
SVN 1.7.0 might be. So, not an option right now.
1.6.10 or 1.6.100 would require explicit communication
to the users. Technically, there is no difference to any
other release number:
* Fixes to old maintenance lines are extremely rare.
IIRC, we did that only once. I.e. no need to support
1.6.7 over a longer period of time (download must
remain available, though, for w2k users).
* Different TSVN cannot be installed side-by-side
except for different bitness. Therefore, we are not
bound to MSI rules about bumping version numbers.
As an exception, a second line of 1.6 would be
manageable. But it does not provide a general solution
to similar feature release problems in the future.
My preferred solution would be switching to an
entirely different scheme: Make the initial release
year the main version number, i.e. "2010.0.0".
People are used to that scheme and it would
clearly signal independent versioning with saying
> If you agree, I'd like to create the 1.7.x branch sometime next week,
> then leave it for another week before we create the final release.
Let's not rush releases. Since this is a feature release,
let the docs catch up. So, branching next weekend
would be fine with me but the release should be 3
or 4 weeks later.
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-13 22:36:28 CET