Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <41CB2EFD.3010805@stason.org>
Date: Thu, 23 Dec 2004 15:47:57 -0500
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
MIME-Version: 1.0
To: "Philippe M. Chiasson" <gozer@ectoplasm.org>
Cc: dev@perl.apache.org
Subject: Re: [Proposal] SVN aware release process
References: <41CB23F0.6060604@ectoplasm.org>
In-Reply-To: <41CB23F0.6060604@ectoplasm.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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