Re: Final version, RFC release process
| From: | Ilia Alshanetsky | Date: | Wed, 01 Jun 2011 11:45:29 +0000 |
| Subject: | Re: Final version, RFC release process | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-52656@lists.php.net to get a copy of this message | ||
> 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.