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.
> /> Immediately after that TSVN-trunk may be switched to SVN-trunk. /
> /> /
> /> Don't get me wrong. I'm always working with nightly builds from /
> /> TSVN-trunk and am quite comfortable with that, but releasing based on /
> /> Subversion trunk seems a bit risky to me. /
> We linked our trunk against the svn trunk before without any problems.
> Of course not for the releases but for the nightly builds. And that's
> what we will do again.
Looking forward to it ;)
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-05-12 12:31:36 CEST