On 13.02.2010 22:36, Stefan Fuhrmann wrote:
> 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 [1].
>>
> 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.
Well, I believe it when I see it. First the branch date was last summer,
then moved back to the end of the year, and now even further.
>> 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.
It's not "just for the features" but because of Win7.
>> 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.
Yes, the trunk builds do not run on win2k anymore.
>> 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
> "detachment".
I like that idea. And it even allows to keep a 'stable' number.
So '2010' would be the major number, the second one the minor number,
allowing us to ship new features, and the third one would be used to
ship bugfixes.
>> 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.
Well, first we have to all agree on a version number and whether we
should go ahead with that release.
Then we wait about two weeks for the docs to catch up and then create
the branch.
As for the release, waiting long after creating the branch won't help
much since very few people will install the nightly builds from there to
test but just wait for the final release.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2447394
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-14 08:35:43 CET