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 The current version is aimed to give early access to new features, to avoid cases like traits which take years to come out while a bit more conservative users (and maybe distros) may stay on the LTS. Once a new "current" comes out there won't be fixes for the previous anymore. Every n-th "current" release will be a long term supported (LTS) release receiving only only only bug fixing and the older it gets the more critical bugs, only. What "long term" means can be discussed. It is open for discussion if a LTS version will directly terminate the previous LTS version or whether an LTS version will be released instead of an "current" version, so for one period there would be two LTS but no "current" branch. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
