I think SemVer 2.0 is a fine starting point, but as others have already mentioned we need a few more specifics (similar to what is outlined in the Accumulo API doc you linked [1]).
Generally speaking, I think there are at least three main issues (probably more) that we need to address regarding maintenance: 1. Length - How long do we want to maintain a release? 2. Content - What exactly is the maintenance? Does it only include CVEs? Does it include all bug fixes? Does it include small features that might normally go into a minor release? 3. Scope - How many branches are we going to maintain concurrently? Do we want to just maintain the two most recent? Do we tag one with "LTM" every so often? If so, how is the decision made about which one to tag? Specifically regarding Accumlo's versioning document [2], I really like the disclaimers that the doc: - is a "declaration of intent" - uses "LTM" rather than "LTS" in order "to avoid any implication of warranties from the use of the words 'support' or 'stable'." - refers folks to the Apache License 2.0 (which ultimately states the software is provided "as is" with no warranty) I think it should be clear that the community is not responsible for support SLAs, etc. like one would expect with a commercial vendor. It might also help to identify a general process for maintenance. For example, commit to the latest branch first and then cherry-pick that commit back onto maintenance branches. Justin [1] https://accumulo.apache.org/api/ [2] https://accumulo.apache.org/contributor/versioning On Mon, Dec 9, 2024 at 7:14 AM Christopher Shannon < christopher.l.shan...@gmail.com> wrote: > There's been some discussion brought up about versioning as part of the JDK > 17 thread for Artemis so I wanted to break it out into another thread. > > That thread made it apparent that the project doesn't really have any > guidelines on how we do versions so I think it would be a good idea to > decide on our versioning policy going forward and what we are allowed to > change between major/minor/patch releases. We don't have to actually adopt > SemVer 2.0 but it's a good starting point for discussion. > > As a good example on another project, I'm also on the PMC for Apache > Accumulo and we have a policy defined for long term releases and we also > adopted SemVer 2.0 and have a well documented policy on it: > https://accumulo.apache.org/contributor/versioning > > Accumulo has also defined the public API and what is actually guaranteed to > change only in accordance with SemVer 2.0: > https://accumulo.apache.org/api/ > Any code outside the public API does not need to follow SEMVER and can > change in any release. This reduces the burden because trying to be super > strict for all code would be pretty hard to do and not necessary. > > Thoughts? >
