You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by "Philippe M. Chiasson" <go...@ectoplasm.org> on 2004/12/23 21:00:48 UTC
[Proposal] SVN aware release process
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
Re: [Proposal] SVN aware release process
Posted by Stas Bekman <st...@stason.org>.
Philippe M. Chiasson wrote:
> 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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org