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
