To achieve stable community release without hampering feature development, we have defined new branching and release policy.
Branching and PR
###Definitions:
develop Branch: All new feature developments will go in develop branch
staging Branch: This branch serves as a release candidate. Before a week, release team will pull the feature from develop branch to staging branch. EG: if the feature is in 25 July’s milestone then it should go in staging on 19th July.
master Branch: master branch serves as a stable branch. This will use as production deployment.
hotfix Branch: mainly define for support issues. This will include bugs or any high priority task like security patches.
Where to send PR?
If you are working on a new feature, then PR should point to develop branch
If you are working on support issue/bug/error report, then PR should point to hotfix branch
While performing testing on Staging branch, if any fix needed then only send that fix PR to staging.
Release Policy
- Release for community
On Tuesday, we will release from staging to master.
Versioning:
Given a version number MAJOR.MINOR.PATCH, increment the:
MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
- Prepare staging branch
On Wednesday, develop will be merged into staging. staging branch is a release candidate. All new features will first go from develop to staging and then staging to master.
We will perform testing on staging branch and make it stable before community release.
We request all advance developers/users from community to use a staging branch and report issues or bugs on github.
- Releasing hotfix
Depending on priority, hotfix release will take place.
Versioning:
PATCH version when you make backwards-compatible bug fixes.
With the new release cadence, the addition of a staging branch seems unnecessary.
If an issue reaches staging, and then requires a fix because of a bug, that fix will be pushed to staging, which then needs to be merged back into develop, and then staging is merged into master. However, before staging is merged into master, a hotfix could have been released, so hotfix needs to be merged into staging/master/develop. It becomes a circus…
What is the problem with the existing develop/master/hotfix setup with twice weekly releases?
The feature that gets merged just before release does not get tested. So we need at least 1 week for a feature to be tested.
Only bugs in staging get merged into staging, so they just have to be pushed back to develop. Bugs in master get pushed to hotfix so hotfix needs to be pushed back to staging and develop.
Fair enough. The only other alternative I can think of is to tag pull requests based on release (which is somewhat happening right now) - that also has its own downsides though.
If this method will be the way to work, I propose to change the name of the branch of ‘staging’ to ‘release’. In this way we can use gitflow which is a widely used method of workflow, and compatible with a lot of tools, Atlassian Sourcetree [1] for example.
Is there currently a way to flag issues in the staging branch? The staging branch shouldn’t get released as master unless all those issues are resolved, but right now it doesn’t seem like there’s a way to see what issues are present for it.
Issues can be tagged by branch, if you commit that staging/release branch to remote and tag issues in that branch you know what issues are resolved and pending review. I think that this pic [1] explains better.
