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
> * 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
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-05-13 10:15:35 CEST