Branching & Labeling BCP

[stevenhartley]

Question was brought up today during the weekly uProtocol sync up meeting about how do we handle stable releases vs development. Currently we merge new changes to main for up-spec and up-rust however other projects work with development branches that are merged on main and main is a stable release. Benefit of the former is that nightly builds can notify developers of changes to their code that need to be made to incorporate spec changes (that break build), whereas the latter means that consumers of libraries don't need to pull a label/branch but can pull main to get the latest "stable" version.

Drawbacks of the former (i.e. we develop in main and have branches for stable releases) is that consumers need to pull a given version/branch, this actually can help to solve our current predicament that there is no way (other than reading the manifest files) to link a release of a language library (ex. up-java) to a given specification release.

Below are the branching & tagging BCP for repositories under Eclipse-uProtocol project:

• Development of latest specification version SHALL be on main
• MUST create release branch prior to working on next specification update (ex. we create a 1.5.7 branch off main before starting to work on 1.5.8
• Release branch SHALL be the uProtocol version (ex. up-v1.5.8, up-v1.5.9)
• Release tags SHALL use the uProtocol version appended with a library specific SEMVER value (ex. up-v1.5.9-0.1.1

[gregmedd]

I love this change. It's really been bothering me that there wasn't a clear way to indicate what version of the uprotocol spec a library was implementing. I do have a couple of questions:

• Will libraries be expected to present that whole version (i.e. up-v1.5.9-0.1.1) in their packaging? Or will they only present the SEMVER?
• If the whole version is included, then does the SEMVER reset for each uP spec version?
• If not, should we provide guidance on what the SEMVER should be for the libraries and how to update them?

Admittedly, that last question is mostly on my mind due to the API rewrite in up-cpp. It's a major change to the API, so it doesn't make sense to just increment the patch, even though that's what all previous updates have done. IMO, we would need to go from 0.1.4 to 1.0.0 with this update. It's just unclear to me if there are some special rules being used for uP packages, or if we just follow the general SEMVER rules.

[stevenhartley]

• Will libraries be expected to present that whole version (i.e. up-v1.5.9-0.1.1) in their packaging? Or will they only present the SEMVER?
  Adding the full version will make it explicit and easy to know which protocol version the library is for so I propose putting the full label in the package name

• If the whole version is included, then does the SEMVER reset for each uP spec version?
• If not, should we provide guidance on what the SEMVER should be for the libraries and how to update them?

Yes we should provide more guidance and be consistent across the various libraries but it should follow the general semver rules for major, minor, patch.

[PLeVasseur]

And not reset the SEMVER, if I'm reading between the lines correctly?

[gregmedd]

So for example, the next bugfix release of up-cpp would be made from the up-v1.5.7 branch with tag up-v1.5.7-0.1.3, right?

And then the next major planned release will be up-v1.5.8-1.0.0 (with a major version rev since it is an API-breaking change).