On Wed, Jun 1, 2011 at 1:45 PM, Ilia Alshanetsky <i...@prohost.org> 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.
yes, and we can adapt that in time and when necessary. The core of this RFC however is still valid and is a very good step forward for our project (that's for Derick's reply). 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
