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
