Branching Strategy

[davemoore-]

Goals

Standardize a branching strategy to facilitate collaborative development.

Proposal

Main Branch > Feature Branch > Release Branch

Syntax

• Main branch: master
• Feature branch: kebab-case-feature-name
• Release branch: {major}.{minor}.{patch}

Strategy

• Main contains the latest production-ready code state.
• Feature branches from Main. Contains code for a feature, bug fix, or other change. Merges to Release after tests pass.
• Release branches from Main. Contains Features in preparation for a release. Merges to Main after tests pass.

[austince]

Thanks for starting this discussion. Generally looks good to me! I just have a few questions/ ideas about release branches:

• Do we want the ability to backport features onto old {major}.{minor} releases? ex: If we wanted to support bulk operations on elasticsearch 7.6 we'd have to patch an old release branch that still supports it.
  • If so, we might treat release branches as more "permanent" fixtures, and cherry pick from Main as we're staging releases. Some good examples of projects that use this strategy are Kuma (which has a nice release guide) and Flink.
  • This would also allow us to easily release nightly snapshot builds from Main, and more importantly candidate versions by just tagging a release branch with something like {major}.{minor}.{patch}-rcX to allow people to test new features before they're officially released, and development can continue unabated on Main.
  • Main would then not necessarily hold production-ready code, and the flow would always be from Main towards release branches in the format {major}.{minor} or release/{major}.{minor}

[davemoore-]

Do we want the ability to backport features onto old {major}.{minor} releases? ex: If we wanted to support bulk operations on elasticsearch 7.6 we'd have to patch an old release branch that still supports it.

I'd separate this into two parts:

• Backporting to older versions of zentity: Possibly yes. However, I think the incentive would have to be strong, given the next point:

• Backporting to older versions of Elasticsearch: Probably no. Elasticsearch has a fairly rapid release cycle and short EOL window (source). Since zentity releases at a slower pace, it makes sense to encourage people to use the more recent versions. But the real blockers are breaking changes in the Elasticsearch Java API. The reason that zentity 1.6.1 only goes back to Elasticsearch 7.7.0 is because the Java APIs that zentity requires changed at 7.7.0. This has happened a few times in the past, and has always determined how far back time zentity will support Elasticsearch.

The net effect of Elasticsearch moving faster than zentity, and periodically changing its Java APIs, means that backporting in general will be difficult, and probably best done as one-offs for people who are motivated enough to request them. Unless zentity somehow blows up in popularity and this becomes impractical.

Aside from backporting, though, I see the merits in what you're proposing. Another merit is automatically acknowledging contributors:

You can view the top 100 contributors to a repository in the contributors graph. Merge commits and empty commits aren't counted as contributions for this graph. (source)

I want contributors to get recognition for their work. The contributors lists that GitHub generates are one good way to do that. But only those who merge into Main will get that recognition. Your proposal facilitates this.

Can you confirm if I've correctly interpreted (below) the flow you described?

• Feature branches from Main
• Feature merges into Main
• Release branches from Main
• Release cherry picks from Main
• Release tags are applied to Release

[austince]

That makes a lot of sense in regards to the ES versioning, and a nice addition for the contributor counting we'd get "for free". And yes, I think that flow is exactly what I had in mind.