[GitHub] [incubator-superset] DiggidyDave commented on issue #6131: [SIP-12] Proposal for Branch Management and Release Process

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

DiggidyDave commented on issue #6131: [SIP-12] Proposal for Branch Management and Release Process
URL: https://github.com/apache/incubator-superset/issues/6131#issuecomment-475691949
 
 
   I wanted to chime in here to recommend consideration of [Git Flow](http://nvie.com/posts/a-successful-git-branching-model/) for the branch/tag/release mechanics. I think it is largely compatible with the broad ideas of SIP-12 described above, but has some benefits:
   
   - it is very Google-able: [documented](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) by [lots](https://danielkummer.github.io/git-flow-cheatsheet/) of [other](https://yakiloo.com/getting-started-git-flow/) [folks](https://blog.axosoft.com/gitflow/)
   - ubiquity: battle-testing and trouble-shooting has been [done](https://softwareengineering.stackexchange.com/questions/tagged/gitflow) and [discussed](https://stackoverflow.com/search?q=gitflow) by others
   - [community](https://jeffkreeftmeijer.com/git-flow/) has built [mature](https://github.com/nvie/gitflow) [gitflow](https://github.com/petervanderdoes/gitflow-avh) [tooling](https://github.com/petervanderdoes/git-flow-completion) for those who like tools to automate the mechanical bits
   
   It also is built around merging and does not include cherry-picking as a matter of course, which keeps history correct and intact. Cherry picks would be rare and used only [when absolutely necessary](https://stackoverflow.com/questions/1241720/git-cherry-pick-vs-merge-workflow/1241829#1241829).
   
   ## A nutshell version of what the above SIP-12 process might look like with gitflow:
   
   Note, gitflow uses a `develop` branch for baseline development rather than `master`, and `master` only contains merge commits from release or hotfix branches.  Every commit on master is a tagged release. (see the linked docs above). This is nice because _CI can automate release mechanics upon merge to master, knowing it is downstream of all release approvals, testing, voting, etc._
   
   ### Daily Development
   
   1. **Do feature development against develop branch.** Feature, bug-fix, and other "task" branches undergo testing in the feature branch for approval, get merged into `develop`, which should be as close to releasable as possible at all times (it is the new `master` for CI/CD purposes).
   2. **Fix serious non-regression issues (requiring patch in old releases) in the earliest branch that contains them, and merge forward** If a bug is found which existed in one of the prior 2 supported releases, and it is serious enough to require a patch release then fix against the first such release, then upward through later previous releases, release branch (if any exist at the moment), then develop.
   
   ### Releasing
   
   1. **Cut release branch.** Lots of feature development, bug fixing etc has been going on and merged into `develop`.  Now we cut a `release/1.0.0` branch from `develop` (which is _in an ideal world_ fairly stable already because adequate testing is occuring prior to approving merges into `develop`).
   2. **Fix release-blockers on release branch.** No cherry picking. If a regression or new-feature blocking bug is found it is fixed on the `release/1.0.0` branch, then merged into `develop`. If a non-regression bug is identified (ie one that existed in previous releases), it can be fixed in `develop
   3. **Tag and publish release candidates as desired.** This could be automated to be as often as for each fix on release, if `develop` is stable enough going into release that we don't have floods of commits going into the `release` branch.  Obvs that's where we would _like_ to be, but easier said than done.
   4. **Approve release** Do the needful things. Convince selves that it is tested. Bugs are fixed. Votes happen etc.
   5. **Release**. Merge the `release/1.0.0` branch to master, tag the commit v1.0.0, delete the release brach.
   
   ## A Note about Semver
   
   I just wanted to note that I've had success in the past using a semver scheme where the "version" of a build is automatically generate using a combination of:
   1. a major-minor version declaration in source; I used a version.txt file, for ex.. it must be manual since people building the product are the only ones who know when a change is a major/breaking change or a new feature/minor change (both of which would require an update to version.txt), or just a patch release. 
   2. the output of `git describe --tags`
   3. previous tags on the history
   
   For example, imagine the repo's most recent release tag is `v1.2.3` (the release.txt file contained `1.2` for major/minor version), and I cut a branch `fixBug1`. If I run `git describe --tags` on that branch with no new commits, it will initially show `v1.2.3`.  If I make one commit, the output would become `v1.2.3-1-a83f0c33`, which is the most recent tag, the number of commits on top of it, and the sha. Tooling can easily compare that to the major/min version in the file and produce a pre-release semver version string of `1.2.4-fixBug1.1.a83f0c33`, which is to say the first commit toward future release 1.2.4 on branch `fixBug` with a sha of a83f0c33. 
   
   This sort of version string (which is 100% semver compliant) makes it very easy to go from user-facing version strings to the exact source commit that produced it. This is very useful when trying to reproduce bug fixes or confirm that a deployment actually happened, etc.

----------------------------------------------------------------
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