On Feb 02, 2011, at 09:18 PM, Jesus Cea wrote: >On 02/02/11 19:47, Antoine Pitrou wrote: >> I don't think we are talking about branching after rc1 but after beta1, >> so that the feature branch can continue receive non-bugfix patches. >> That's quite many changesets to review. > >A beta is like any other branch. The "canonical way" (TM) in mercurial >is to write the patch for the "oldest" supported branch (in this case, >the beta branch), and "up-port" it to the open devel repository. > >So, RM could say something like "beta branch is here. Commit there only >things that MUST be in 3.3.0. For general development, commit to >"py3k"". Anybody can merge from "beta" *TO* "py3k", for "up porting". > >The trick here is to patch the oldest supported version, and "up port" >later, via mercurial merge. > >Just exactly the reverse of current workflow.
And for good reason (IMO). It's often much less clear exactly how far back a specific patch should be committed when it's first being developed. It makes much more sense to me to fix a problem in the current development branch first, and then determine if, how, and where the patch should be back ported. -Barry
signature.asc
Description: PGP signature
_______________________________________________ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
