+1 for a branching model with master as current dev, release branches for release development and fixes, and tags for marking release points. > > ** What will we call our branches?* > -> development (current the master) > -> v0.x-stable > -> v1.x-stable > -> v2.x-stable (v0.x-stable is deleted) > -> v3.x-stable (v1.x-stable is deleted) > Each branch would have multiple tags marking the minor releases.
In general I don't care what the dev branch is called, but in my experience, Git-life is easier when master is the branch where development occurs. On Sat, Feb 13, 2016 at 8:44 PM, Andre <[email protected]> wrote: > I am not a git specialist but I can share my view as a user: > > ** What will master look like while we're doing this?* > I've noticed depending on the project a master branch can be a stable > branch or a development branch and as long the behaviour of the branches is > clearly documented, the approach used is secondary. (except on golang > project where rules apply). > > ** What will we call our branches?* > > -> development (current the master) > -> v0.x-stable > -> v1.x-stable > -> v2.x-stable (v0.x-stable is deleted) > -> v3.x-stable (v1.x-stable is deleted) > > Each branch would have multiple tags marking the minor releases. > > Ditching master as a name will clearly state the intent of the branch and > allow the user / developer to know that by running on that version you are > from cutting edge. > > Having said that I suspect there are some minor issues about getting a git > without master to run on github [1]but given the project uses the ASF bot > and github replication it may worth checking if this is possible. > > Independently of the name master would be cutting edge and things could > break. > > ** Who would integrate patches and PRs into multiple versions? > Reviewer? Submitter? Or would this be another ticket?* > > If it is a new feature (e.g. new listener) it should be up to the submitter > to decide if support would be extended to currently stable release or would > reside just on the development branch. > > The key IMHO aren't the features but changes to shared code; as long we > prevent changes to existing classes and method signatures I think we would > be following the right track. > > It should be paramount to provide stability to code crafted outside the > project (a perfect example being NATS messaging processor that was never > merged into the project [2]) without hindering development of the product > within minor releases. > > Regarding bug fixes, I think anyone would be welcome to submit a fix to any > of the supported branches. > > ** What project does this well and could be a model?* > > I think a good model to look at is the one adopted by rsyslog project. > > If I'm not mistaken they adopt a release branch model. > > v7.x is no longer improved but still available for bug fix backport into > minor releases (controlled via tags). > v8.x stable is there and has tags for each of the minor releases. > master is the development tree > > ** Should we decide to only have one version "supported" at a time to > avoid this?* > > I reckon that nowadays the minimum expected by user base is major - 1 as > this prevents the requirement to adopt rolling releases. > > Also, by supported I mean security fixes and critical issues that may lead > to data loss and system crashes. features, nice to haves and other things > are up to a number of factors and I may or may not get them backported. > > Those who have ever dealt with RHEL know that you may ask RH to backport > feature blah to "version - 1"... you may ask, but truth is that sometimes > you will get it, sometimes you won't. > > Cheers > > > [1] https://matthew-brett.github.io/pydagogue/gh_delete_master.html > [2] https://github.com/mring33621/nats-messaging-for-nifi >
