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
