Re: Branching PHP6
On Thu, Apr 3, 2014 at 5:20 AM, Johannes Schlüter <[email protected]>wrote:
> On Thu, 2014-04-03 at 04:32 -0700, Kris Craig wrote:
> > By release branch, are you referring to minor releases or maintenance
> > releases? If the latter, it'd be a moot point under this model because
> > we'd be getting rid of separate branches for maintenance releases
> > altogether. Instead, the RM would simply apply the tag to the commit
> where
> > they want the maintenance release to occur. That would be a much cleaner
> > approach than what we're doing now.
>
> The past shows that in practice this won't work. We had enough incidents
> in the past where "small" changes after an RC roe the release. That's
> why we created the strict rule of using those release branches.
>
That wouldn't happen if the RM controlled commits to the minor release
branch.
>
> > If you want to continue having a gatekeeper approach with only one person
> > having access to a minor increment branch, a simple alternative would be
> to
> > have people push their feature branches if they believe the commits
> should
> > go on one or more minor increments. Then, the release manager for each
> > minor increment (i.e. there'd be an RM for 6.0 and 6.1 instead of for
> each
> > individual maintenance increment) would decide whether or not to merge
> that
> > feature branch in. The feature branch itself would be based on a minor
> > release branch and subsequently deleted after it's either merged or
> > rejected.
>
> Neither do we have the resources for constant gatekeeping nor is that
> the spirit. In general we trust developers to do the right things and
> prefer fixing mistakes afterwards over preventing improvements by
> process.
>
Actually, that's extremely easy to accomplish with Git. Gitolite, for
example, enables the use of branch-specific permissions for different users..
Besides, my point was that this branching model can easily accommodate both
scenarios with and without a gatekeeper.
>
> The reason why we have the "ugly" history comes more from the fact that
> we have long living feature branches branched of quite some time ago
> (i.e. pull requests) which then are merged in, instead of e.e. rebaseing
> the first.
>
>
That's part of it, but I've also noticed a ton of criss-crossed merging
happening between version branches. That, more than anything I think,
makes it a nightmare to read. Furthermore, there's simply no need to have
an ever-increasing number of dead branches that lead nowhere and never
merge back. If somebody wants to find a specific version, that's what tags
are for.
--Kris
Thread (16 messages)