Re: [mp2] code freeze

Stas Bekman wrote:

> Philippe M. Chiasson wrote:
>
> > Stas Bekman wrote:
> >
> > > in case you haven't noticed i've posted an RC, so we enter the code 
> > > freeze phase. So please avoid committing code changes, unless they 
> > > are fixes of something that's broken (e.g. tests).
> > >
> > > I think we may want to change that practice in order not to create 
> > > obstacles for new development. We should TAG the release candidate 
> > > as a release and then move the tag if some post release candidate 
> > > fixes should be included. I'm not sure why Doug didn't like that 
> > > idea in first place.
> >
> >
> >
> > Well, personally, I am not a fan of moving tags. Why not just make a 
> > short
> > lived branch for release-candidates? The small fixes that apply to it
> > can be contained to that branch. Then later merged back to the HEAD 
> > by the release
> > manager of that RC once it's ready for release?
>
>
> That works for me.
>
> So on the release date we just add a new tag for the release one?

Yes, so typical scenario :

= Gozer volounteers to be release manager for 1.99_17
= New branch from HEAD => mod_perl_1_99_17_RC1
= Adjust version number and stuff on the branch and check in
= Tar the branch and publish as RC1
= Make RC1 bugs fixes on the branch
= When ready for RC2, tag the branch mod_perl_1_99_17_RC2
= Tar the branch and publish as RC2
= When ready for release, adjust the RC2 branch to reflect release 
version numbers, etc.
= Tar the branch and publish as 1.99.17
= Merge the now dead branch back to HEAD
= Bump version numbers to start the next -dev cycle

signature.asc
Description: OpenPGP digital signature