Sounds reasonable. 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 > > 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
