After going thru making the first release after our move to subversion, I'd like the opportunity to discuss a possible change to how we make releases.
Our current release process is a good one, but it was built around CVS's limitations.
So in this proposal, I'd like to solve a few problems.
1. Ability to make release-candidates and releases without holding up development 2. Ability for someone to take over an unfinished release-candidate and push a release out 3. Ability to make release-candidate fixes in isolation
The following is my suggested release process:
In this scenario we are getting ready for 1.99.20
So, first we take HEAD and prepare it for the RC $> svn cp https://[repos]/trunk https://[repos]/branches/1.99.20
Then we switch over it $> svn switch https://[repos]/branches/1.03/1.99.20
We bump versions and such in preparation for the RC $> vi Changes README Makefile.PL $> svn ci Changes README Makefile.PL
We make the release-candidate $> perl Makefile.PL && make dist
[Here we could keep on modifying the branch if RC bugs are found]
We are happy with the release-candidate, so now it's official
First we make the branch a tag
$> svn mv https://[repos]/branches/1.99.20 https://[repos]/tags/1.99.20
Then we switch over to it
$> svn switch https://[repos]/tags/1.99.20
And make the _official_ package $> perl Makefile.PL && make dist
RELEASE IT!
Then start the new dev cycle.
Switch back to the head $> svn switch https://[repos]/trunk
Apply (merge) changes to the RC to the trunk/ $> svn merge https://[repos]/trunk https://[repos]/tags/1.99.20
Bump version and such $> vi lib/mod_perl.pm Changes STATUS RELEASE
Check in $> svn ci lib/mod_perl.pm Changes README Makefile.PL STATUS RELEASE
Comments welcome! -- -------------------------------------------------------------------------------- Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
signature.asc
Description: OpenPGP digital signature
