Philippe M. Chiasson wrote:
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
Why do we need branching? We were talking only about tagging
--
__________________________________________________________________
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]
