Stefan Küng wrote:
> So Subversion 1.3.0RC4 is out, which means the 1.3.0 release isn't
> that far away anymore. It's time to think about the next TSVN release.
Still 4 weeks minimum soak time before Subversion 1.3.0. This is the
first official release candidate - none of the others made it past
signature stage.
> My plan (subject to change, please comment!):
>
> * get the cache to a state where Peter is ok with it (hmmm - maybe
> we'd have to make the release earlier, people might get angry if we
> don't release for another two years ;)
> * change the build to use VS.NET2005 (that also means that people
> using the free VC-Express can build TortoiseBlame, SubWCRev, ResText,
> ... without any problems)
> * Maybe even get it to build for 64-bit
>
> Then, when Subversion 1.3.0 gets released:
I think we can and should do our own RC sooner, against SVN RC4. I'm
sure we have done that in the past, and not waited for the final release
before doing our RC1. It's been a long time since our last release from
trunk and we need to get some more exposure to testing.
> * create a branch from trunk, named "1.3.x".
> * release an RC1 from that branch
> * wait a week to give people time to test RC1
> * fix bugs found in RC1, merge them back to 1.3.x
> * if fixedbugsinRC > 3 OR peoplerequestinganotherRC goto -3
> * release 1.3.0
>
> Keep working on trunk, implementing new features. But 1.3.x releases
> will be made from the 1.3.x branch, not from trunk anymore. And they
> will *only contain bugfixes*, no new features or other changes.
This is a very much more conservative policy than we have used before -
similar to the SVN one. That means no new TSVN features until SVN 1.4,
which is likely to be 6 months away. Is that really what you want to do?
In the past this has caused problems because an important ease-of-use
feature did not qualify as a bugfix and users had to wait a long time
for it. Also, merging the bugfixes and doc updates has been a real PITA
and we quickly got fed up with it.
Have you looked at www/release_faq.html lately? That explains why we
generally cut releases from trunk. We want SVN to adopt a conservative
policy, but we don't need to.
Modified version of your procedure:
* Pause major development on trunk - use a dev branch if needed.
* do {
* Release an RC from trunk, using SVN RCx or full release.
* Wait a week to give people time to test the RC.
* Fix bugs found in RC directly in trunk.
* } while (fixedbugsinRC > 3 OR peoplerequestinganotherRC)
* Release 1.3.0.
* Merge any dev branches back to trunk and resume trunk activity.
Use this method for all releases except ...
When SVN cuts the next minor release branch (1.4.x), we produce a 1.3.x
branch then switch our trunk to build against the 1.4.x branch. At that
point, our 1.3.x releases come from the branch and contain only
bugfixes. In that case:
* do {
* Release an RC from that branch.
* Wait a week to give people time to test the RC.
* Fix bugs found in RC, merge them back to 1.3.x.
* } while (fixedbugsinRC > 3 OR peoplerequestinganotherRC)
* release 1.3.x.
Simon
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Nov 30 18:25:32 2005