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!
One things doesn't make sense to me. Why
"Bump version and such"
if we are already in the dev of a new cycle and potentially committed a bunch of things. This should be done as soon as you fork things.
fork and "Bump version and such in the HEAD"
but that's still not good timing wise.
I think it should be:
1) Make a release (remove -dev adjust date and commit Changes)
2) fork (and continue working on the fork for RC => release)
3) updated HEAD to start a new dev cycle.
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
