On 7/18/2010 5:05 PM, Alexander Belopolsky wrote:
On Sun, Jul 18, 2010 at 4:32 PM, Paul Moore<p.f.mo...@gmail.com> wrote:
On 18 July 2010 20:57, Glyph Lefkowitz<gl...@twistedmatrix.com> wrote:
..
This is what branches are for.
When the X.Y release cycle starts, there should be a branch for X.Y. Any
"would be applied" patches can simply be applied to trunk without
interrupting anything; the X.Y release branch can be merged back into trunk
as necessary.
Agreed. If that isn't already the recommended workflow under
Mercurial, I'd suggest making it so. (I can imagine that under
Subversion, where branching and merging is more awkward, it might have
been deemed not worth doing).
Do I understand it correctly that the proposal is to create an
X.Y-maint branch at the time when alpha (or beta) release goes out
rather than the current practice of creating the branch at the time of
the final release?
I would understand it to be at the point when some commits would
otherwise be deferred and possibly forgotten. Whick is to say, first
beta. I would expect that partial and then nearly complete closure of
'trunk' would work best if there were only a few committers who nearly
all turn to bugs and then critical bugs during the beta and rc phases
and who would not look at anything else during those phases. Of course,
it would be best if pending patches for known bugs were applied before
the split, so that the only patches applied to the new branch were for
newly discovered bugs.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
