Geoffrey Young wrote:
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
yeah, man that's _way_ too much work.
IMO, it's not much work ;-)
personally I don't see the problem. our dev cycles are short enough that we shouldn't really need to worry about any of this - we go from RC to release in about 2 days, during which time any work should be focused on fixing RC issues. if there are no RC issues take a break, go swimming or for a hike through the woods. enjoy life a bit...
I agree that so far, our development process has never been seriously harmed by release-candidates and I am more than happy with the way we currently do things.
I just pointed out what I thought was a _good_ solution to avoid code-frezes.
--Geoff
-- -------------------------------------------------------------------------------- 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
signature.asc
Description: OpenPGP digital signature
