-
-
Save trevnorris/7620a64b086e95271197 to your computer and use it in GitHub Desktop.
| The following diagram is a simplified, and as accurate as possible, scenario of | |
| branching and merging if breaking development was done on the next branch, with | |
| periodic versioned releases of next every 6 weeks, stable development done on | |
| the master branch then cutting a new branch every other release for LTS. It | |
| does not take into account the six week offset of the V8 release and the fact | |
| it doesn't line up with specific days of the year. So merging from next to | |
| master would happen in the middle of a development cycle. | |
| One worry I have about this approach is it will make bisecting issues more | |
| complex. If not impossible. Another is the amount of cognitive overhead needed | |
| to make sure all of it happens correctly. Automation cannot help with merge | |
| conflicts. | |
| o---o---o---o | |
| / | |
| LTS o---o---o---o---o---o---o---o o---o---o | |
| / / | |
| master o---o---1---o---o---o---3---o---o---o---5---o---o | |
| \ / \ / \ / | |
| next-R 1---o 2---o 3---o 4---o 5---o 6---o | |
| / \ / \ / \ / \ / \ / \ | |
| next o---o---o---o---o---o---o---o---o---o---o---o---o | |
| The following diagram represents my optimal scenario for development. It is the | |
| simplest to cognitively reason about. It has the advantage of working well with | |
| LTS. Since each current major release is its own branch the LTS team simply | |
| needs to take it over. The branch separation makes it simpler to bisect any | |
| issues that come up. It is a very common approach. V8 uses this same method of | |
| cutting a release branch every six weeks. | |
| o---o---o---o | |
| / | |
| LTS o---o---o---o---o---o o---o---o | |
| / / | |
| release 3---o---o 4---o---o 5---o---o 6---o---o | |
| / / / / | |
| master o---o---o---o---o---o---o---o---o---o---o---o | |
| The following is a minor revision of the previous plan. The difference is it | |
| shows the small overlap when two majors are supported to give the community | |
| some time to migrate their modules. Basically the major is cut and then for | |
| some, yet to be specified, time it is not published as the latest stable, but | |
| it is stable for the purpose of allowing the community, especially native | |
| module authors, to be prepared. | |
| o---o---o---o | |
| / | |
| LTS o---o---o---o---o---o o---o---o | |
| / / | |
| stabilize o---o o---o o---o | |
| / / / | |
| release 3---o---o 4---o---o 5---o---o 6---o---o | |
| / / / / | |
| master o---o---o---o---o---o---o---o---o---o---o---o |
Fishrock123
commented
Jul 20, 2015
o---o---o---o
/
LTS o---o---o---o---o---o o---o---o
/ /
release 3---o---o 4---o---o 5---o---o 6---o---o
/ | | | | / | | | | / | | | | / | | |
master o---o---o---o---o---o---o---o---o---o---o---o
\ \
4.0.0-beta.1 5.0.0-beta.1
\ = merge
| = cherry-pick
Cherry-pick UP from master into oldest desired branch
Where does the integration work for that 5.0 happen prior to landing in master?
As I understand @Fishrock123's proposal, all commits are made to master then ported up to the appropriate release line branches. This presents an interesting opportunity, given the following:
- We are no longer required to semver-tag PRs before landing them (in particular, we are not required to identify breaking changes ahead of time.)
- Non-breaking changes may be backported (via cherry-pick) up to "more stable" release lines.
One of the big problems io.js has run into is the difficulty of maintaining a standard definition for stability. We've implicitly spread the work of determining the stability level of individual PRs across the collaborator base, and as a result we don't present a super cohesive idea of what stability looks like for the platform. Additionally, there's sort of an incentive to come down on the "patch" side of the "major or patch" determination, since it means the code will reach the public much quicker, and the PR won't have to be retargeted to another branch.
The opportunity the proposal presents is that we can separate the "determination of impact" step from the usual "authoring and merging a patch" flow, and concentrate that responsibility in a role whose sole job is to get commits from the "beta" line to the appropriate places in the "current" and "LTS" lines. It'd be a full-time task, but it would be super valuable — instead of subjecting a PR to multiple conflicting opinions about stability levels, the person filling this role would be responsible for applying the stated dev policy to each commit. As a result, the project would become much more predictable with regards to stability.
It'd be a really visible role that would require a sizable time commitment and a solid understanding of the goals of the project, but it'd create a ton of value by increasing the stability and quality of our release lines and improving communication between the collaborators and end users. Over time the person working in this role may even build up and manage a team of collaborators that concentrate on these responsibilities.