Re: TSVN release cycles

On 12 May 2010 11:31, Stefan Fuhrmann <stefanfuhrmann_at_alice-dsl.de> wrote:
> Stefan Küng wrote:
>>
>> On 11.05.2010 20:22, Tobias Schaefer wrote:
>> /> On 11.05.2010 19:42, Stefan Küng wrote: /
>> />> Sometime this or maybe next week, the svn library will get rid of
>> the /
>> />> double property handling. That means the speed of the new wc
>> format will /
>> />> finally be so that we can use it. /
>> />> So I'll soon switch the TSVN trunk to link against the svn trunk
>> so I /
>> />> can start implementing the new features. Once that's done, we
>> can't make /
>> />> a TSVN release without waiting for the svn release. /
>> /> /
>> /> You surely mean "can make" ;-) /
>> /> /
>> /> If we link to the svn trunk we will not have a stable Subversion
>> basis /
>> /> for a while and will IMHO not be able to release stable TortoiseSVN
>> builds. /
>> /> /
>> /> Why not release the current TSVN-trunk based on the current 1.6.x
>> branch /
>> /> now (after a short beta)? However, the question is if this will be /
>> /> called 1.6.10, 1.7.0, 2.0, or 2010-05 (see prevision discussions). /
>>
>> Sure, we could do that. But as you know, the previous discussion
>> couldn't come to an agreement about what to call such a release.
>> Every one of the suggestions has at least one big drawback, so basically
>> what we do now seems to be the best solution.
>>
> Maybe, I got yet another idea:
>
> * stick with the SVN release schedule for 1.7
> * once 1.7.0 got released, request a guesstimate for 1.8
>    a) believable 6 month time-frame -> stay in sync w/ SVN
>    b) likely to be 9 month or more -> announce change in TSVN release
> policy
> * new release policy (if applicable):
>    - a feature release about every 6 months
>    - the last feature release may be rather close to the next SVN release
>      (but stop releasing new features when SVN enters stabilization)
>    - name releases closely to SVN version numbering:
>       * 1.8.0, 1.8.1, ... for the initial feature set releases
>       * 1.8.10, 1.8.11, ... for the second feature releases
>       * 1.8.20, etc for the third feature release etc.
>      (we don't release more frequently than every 3 weeks,
>      so patch level numbers won't overlap)
>
> That way we wouldn't appear to change policies at a "whim"
> but have plenty of time to inform / educate users upfront, instead.

This general scheme sounds good to me, but I would go for the new
policy regardless of estimated SVN release time frames.

But why wait until after the 1.7 release? We could do the same now
with a 1.6.10 release branch, although I realise the "plenty of time
to inform / educate" will not happen. Realistically 1.7 is still
several months away, and based on past release cycles my guess would
be another 6 months and there are features on TSVN trunk that people
want.

Simon

-- 
:       ___
:  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=2608544
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].