Re: Branching PHP6

On Wed, Apr 2, 2014 at 4:33 AM, Julien Pauli <jpauli@php.net> wrote: > Hey , > > We've been talking about PHP6 for several weeks now. > > From what I understand, we agreed on : > > - We must release a new major version, ASAP I'd say > - It should be named "PHP6" > - It should break BC where needed, and introduce new concepts > - The main concept to concentrate on is Unicode implementation > - All ideas have been grouped at > https://wiki.php.net/ideas/php6 > - We go for a 2 year developpment iteration > > > All in one, 5.6 is going to be released in few months, and we now must > concentrate on PHP6. > > For this, there are two needs : > - Start writing RFCs, PHP6 specific, and start debating ideas on an > "official" basis (RFCs + mail discussions) > - Branch PHP6 , so that we can start hacking and get more motivations. > > Thoughts about how/when to branch PHP6 ? > > > Julien Pauli > I think we should use this opportunity to start following a more Git-style branching model. Currently, every maintenance release increment exists as its own separate branch; i.e. "PHP-5.5.10" is a branch and "PHP-5.5.11" is a branch, and so on. This is redundant because we already have a tag for each release. Additionally, it also forces us to target features for one or more specific maintenance version increments. A more flexible approach would be to have each increment reflect the totality of what's been merged in as stable as of whenever the increment went to release. This can get complicated and confusing so I'll do my best to articulate exactly what it is I'm proposing and why. It's very similar in principle to how the Gitflow model works.. Under the current model (as best as I can decipher from gitk, at least), the PHP-5.4 branch merges into master and PHP-5.5. PHP-5.5 then merges into PHP-5.6. PHP-5.6 (the most recent increment) then merges into master. Each of these minor versions are then branched off into a maintenance version branch every time a maintenance release occurs. These branches eventually just remain dead, at least some without being merged back into anything. It's already a confusing mess and it's only going to get worse at this rate. Just type "gitk --all" sometime and see how much of it you can make sense of without getting a migraine. What I'm suggesting is a cleaner, more logical approach that doesn't force us to keep a dead branch for every maintenance release. Let's start with creating the PHP-6 branch.... 1. Create branch PHP-6 based off of master (master->PHP-6). 2. Commits related to work on PHP 6. See explanation about feature branching below. 3. When we decide we have enough for a minor release, create a new branch based off of PHP-6 (PHP-6->Release-PHP-6.0). - This is the cuf-off point for noteworthy new features and whatnot. - Commits on this branch will pertain mostly to bug fixes and maybe trivial feature changes/etc. - Work on everything else will continue in parallel on PHP-6. - Release-PHP-6.0 will occasionally be merged into PHP-6 (PHP-6<-Release-PHP-6.0). However, commits to PHP-6 will NOT be merged into the minor release branch. - If we have a bug fix that we want to incorporate into an older-yet-supported version, make the change on one of the Release branches then merge it into the other-- if that can be done without creating a merge conflict. Otherwise, we'd want to manually commit it to the others. Just depends on how different the surrounding code is between the minor increments. 4. When the Release-PHP-6.0 branch is deemed ready for a release (commits to that point could be treated as release candidates): - Tag the commit with the maintenance release version. The first one would be "PHP-6.0.0". - This would be a good time to merge it into PHP-6, as well. 5. Repeat Step 4 for the duration of the 6.0 lifecycle. Each subsequent commit tag will increment "PHP-6.0.1", "PHP-6.0.2", and so on. Again: Commits to PHP-6 will NOT be merged here; however, commits here will be merged back into PHP-6. 6. When the PHP-6 branch is ready for a new minor version increment, repeat Steps 3 - 5, except increment it to "Release-PHP-6.1" and so-on. 7. When a minor release's lifecycle is over and we're no longer supporting it (i.e. there will be no more maintenance releases), merge the release branch into PHP-6 (i.e. PHP-6<-Release-PHP-6.0) and delete the release branch. So long as you use the "--no-ff" switch when merging, the complete history for that former branch will be preserved and the chart will look MUCH nicer! This model would allow us to have a much more organized and easy to follow commit history. Every single version increment will still be accessible via tags just as they are now and the temporary Release branches will appear in the history even after they're gone. One of the advantages to this approach is that people will no longer have to decide which minor increment(s) to target something for, nor will they have to worry about having to merge it into a ton of different places. It will also make it a LOT easier to enforce a cut-off for new features/etc into a minor release. It'll force us to limit maintenance releases to, well, maintenance. Meanwhile, if something isn't there in time for 6.2, it'll just go into 6.3 instead if it's ready by then. A developer would then simply have to decide whether something should be targetted for the next minor release (i.e. commit to PHP-6) or whether it's within the scope of a maintenance release (i.e. commit to one or more of Release-PHP-6.x then merge back into PHP-6). On a separate note, as alluded to in Step 2, I'd also recommend using feature branches instead of committing directly into the "trunk" for a given version. For example, I create a LOCAL branch called "Bug_53333" off of "Release-PHP-6.0". I make several commits while working on fixing this bug over the course of several days. When it's done, just like with the Release branches, I merge the feature branch back into Release-PHP-6.0 (using "--no-ff" to preserve the commit history and feature branch name at the merge point) and delete the feature branch. Note that the feature branch is never pushed to the host repo; it exists solely on the dev's local machine. However, when the dev pushes Release-PHP-6.0, the commits and the branch name will appear in the history, which will make it a lot easier to read. Furthermore, this has the advantage of making sure all the commits related to the fix are pushed at once so the release manager doesn't have to worry about a partial bug fix sitting there potentially breaking the release, forcing them to either rewind or wait for the other commits to arrive. I didn't include the feature branch part in the numbered list because I wanted to communicate the basic structure as clearly as possible. Furthermore, it'll still work without using local feature branches, though using them solves a lot of problems and makes the history more human-friendly. I realize this may look complicated-- particularly to people more accustomed to Subversion-style branching-- but the benefits far exceed any learning curve involved. Furthermore, we could start doing this with PHP 6; it wouldn't have any effect on how we're doing the branching for PHP 5. If we go with that model, we could get started on the new PHP-6 branch right away or whenever we all decide it's time to get it underway. Thoughts? If it'll help, I can create a mock repo to demonstrate this approach and how much easier it is to review and work with. --Kris