Pierre, Doing a release could be simplified through automation as you've said. However keeping synchronized patches across frequently incompatible (non-identical) code bases is much less trivial and requires quite a bit of work by anyone making the bug fixes. Having >3 branches for bug fixes makes this very non-trivial and time consuming, which is why Johannes' proposal is so appealing.
2011/6/1 Pierre Joye <pierre....@gmail.com>: > hi, > > > 2011/6/1 Johannes Schlüter <johan...@schlueters.de>: >> On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote: >>> > This variant is not workable, because there are (in the example) in 2014 >>> > *five* branches. Merging between those, manually and automatically is >>> > going to be a major pain. I'd say we all rather want to focus our time >>> > on fixes and new features; and not spend more time doing branch merging, >>> > whatever tool we use for this. >>> >>> This is similar to my initial point about the proposal. We need to >>> figure out a way to have fewer active bug-fix branches, just because >>> it make dev live very difficult. Derick I am not sure your example is >>> much better, since you still have 4 active branches (if I am reading >>> the diagram correctly). I think 3 active bug fix branches, with maybe >>> 1 security fixes only branches is the most we should have. >> >> I mentioned this before: I like the Ubuntu model: > >> * One development branch for the next version >> * One current version >> * One "long term" supported version > > I do not like it. It does not apply to a programming language and its > requirement from an end user point of view. > > To have a fixed life span for each x.y (5.3, 5.4, 6.0, etc.) is a > drastic improvement for ISPs, framework developers etc. > > The issue about having multiple or too many branches active is a non > problem imo. Yes, it takes a couple of hours yet to release php, but > that's something that could be automated easily (the tasks, not the > whole thing) . It will also be much safer to do it given that no fancy > commits can or should be applied in patch releases/stable branches. > > In addition we are getting more and more automated testing and that > will make the release processes even smoother and safer. Unlike now > where we need months to do 5.3 patches when we should have at least .7 > already and .8 being in the work. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
