[GitHub] [incubator-superset] kristw edited a comment on issue #6131: [SIP-12] Proposal for Branch Management and Release Process

[GitBox <gi...@apache.org>]

kristw edited a comment on issue #6131: [SIP-12] Proposal for Branch Management and Release Process
URL: https://github.com/apache/incubator-superset/issues/6131#issuecomment-475722202
 
 
   Hi @DiggidyDave, 
   
   Thank you for your comments. When drafting this proposal, @john-bodley, @michellethomas and I did consider **gitflow** and in some aspects it is similar with the process above. However, there are a few differences:
   
   * You could consider the current `master` as equivalent to `develop` in the **gitflow** paradigm, and there is no equivalent of `master` in gitflow. The stable branch is the release branch of the previous version. We adopted this idea from `react.js` which is also a large project that is battle-tested and more suitable with the current workflow of the folks in the Superset community. 
   * We also need to maintain *multiple versions* over time. Now we are maintaining the last 2 minor versions. 
     * Version `n` is the latest release which include all new features since `n-1` 
     * Version `n-1` is considered a stable release. That is why we still add bug fixes (via cherrypick) to it to increase its stability and ensure that the previous version is the most stable one we could have. 
   
   Oftentimes we do not want to introduce all new features into the current stable release but rather apply bug fixes to improve its stability and wait for the next minor release to adopt new features. In **gitflow**, once you are at `1.2.3` and create `1.3.0` , it is not natural to create `1.2.4`. Only `1.3.1` is possible. Users either have to choose between `1.2.3` which has a bug or `1.3.1` which include the bug fix but also has new features that they are not ready to take. For the multi-version support we adopt some ideas from `node.js` LTS branches. 
   
   Please also keep in mind that Superset is a UI project, in which a new feature that does not break the previous version could still greatly affect the user experience. The choice to upgrade from `1.2.3` to `1.2.4` vs `1.3.0` for an organization is not something that can be taken lightly. 
   
   I also would like to point out that another key point of this SIP-12 is we also wanted to clarify the details about time frame and set the right expectation for releases, not just the git workflow. These details are organization-specific and not specified in **gitflow**. We research multiple well-known open-source projects such as `node.js` or `Chromium` and see how they have regular cadence for releases and adapt them into this IP.
   
   ### References
   
   >**React.js**
   Branch Organization
   We will do our best to keep the master branch in good shape, with tests passing at all times. But in order to move fast, we will make API changes that your application might not be compatible with. We recommend that you use the latest stable version of React.
   >
   > If you send a pull request, please do it against the master branch. We maintain stable branches for major versions separately but we don’t accept pull requests to them directly. Instead, we cherry-pick non-breaking changes from master to the latest stable major version.
   >
   > Semantic Versioning
   React follows semantic versioning. We release patch versions for bugfixes, minor versions for new features, and major versions for any breaking changes. When we make breaking changes, we also introduce deprecation warnings in a minor version so that our users learn about the upcoming changes and migrate their code in advance.
   >
   > We tag every pull request with a label marking whether the change should go in the next patch, minor, or a major version. We release new patch versions every few weeks, minor versions every few months, and major versions one or two times a year.
   >
   > Every significant change is documented in the changelog file.
   
   > **node.js**
   node has minor and patches regularly ~2 weeks
   https://github.com/nodejs/node/tags
   https://github.com/nodejs/Release#release-plan
   https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md#how-does-lts-work
   
   > What is LTS?
   Long Term Support (often referred to as LTS) guarantees application developers a 30-month support cycle with specific versions of Node.js.
   >
   > How does LTS work?
   Once a Current branch enters LTS, changes in that branch are limited to bug fixes, security updates, possible npm updates, documentation updates, and certain performance improvements that can be demonstrated to not break existing applications. Semver-minor changes are only permitted if required for bug fixes and then only on a case-by-case basis with LTS WG and possibly Technical Steering Committee (TSC) review. Semver-major changes are permitted only if required for security-related fixes.
   >
   > Once a Current branch moves into Maintenance mode, only critical bugs, critical security fixes, and documentation updates will be permitted.
   >
   > Landing semver-minor commits in LTS
   The default policy is to not land semver-minor or higher commits in any LTS branch. However, the LTS WG or TSC can evaluate any individual semver-minor commit and decide whether a special exception ought to be made. It is expected that such exceptions would be evaluated, in part, on the scope and impact of the changes on the code, the risk to ecosystem stability incurred by accepting the change, and the expected benefit that landing the commit will have for the ecosystem.
   >
   > Any Collaborator who feels a semver-minor commit should be landed in an LTS branch should attach the lts-agenda label to the pull request. The LTS WG will discuss the issue and, if necessary, will escalate the issue up to the TSC for further discussion.
   >
   > How are LTS Branches Managed?
   There are multiple LTS branches, e.g. v8.x and v6.x. Each of these is paired with a staging branch: v8.x-staging and v6.x-staging.
   >
   > As commits land on the master branch, they are cherry-picked back to each staging branch as appropriate. If the commit applies only to the LTS branch, the PR must be opened against the staging branch. Commits are selectively pulled from the staging branch into the LTS branch only when a release is being prepared and may be pulled into the LTS branch in a different order than they were landed in staging.
   >
   > Any Collaborator may land commits into a staging branch, but only the release team should land commits into the LTS branch while preparing a new LTS release.
   
   > **Chromium**
   >
   > Chromium has predefined release schedule with certain dates that a release branch will be cut and estimated date that the branch will be stable (~2 months after the branch has been cut). 
   https://www.chromium.org/developers/calendar
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: notifications-unsubscribe@superset.apache.org
For additional commands, e-mail: notifications-help@superset.apache.org