On Sun, Jul 18, 2010 at 4:32 PM, Paul Moore <p.f.moore at gmail.com> wrote: > On 18 July 2010 20:57, Glyph Lefkowitz <glyph at 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? In this case issue1699259 patch could be committed to py3k branch without affecting what goes into 3.0. I still don't understand why "Python 2.6 is already out" was a reason not to commit it to trunk at the time.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4