We have had a very problematic history with release versioning, such that > our users probably think the numbers are meaningless. >
Completely agree with this. But it feels that we're throwing the baby out with the bath water… I do think we can do semver with just a minimal amount of dev guidelines in place, to great benefit to users (and for ourselves). > However, in the new release lifecycle document (and in follow-up > discussions around qualifying releases) we curtail _features_ once a > release is GA, and also stipulate that a new major version is associated > with a release. > The following aspects remain open questions for me… - if there's no such features, or anything breaking compatibility, isn't there benefit in releasing a minor, - can we better indicate to users the upgrade path (and how we simplify which upgrade paths we have to support), - the practice of deprecating an API one release and then removing it the following, - we have CQL, Native Protocol, SSTable versioning, can they tie in to our semver (especially their majors, which are also about compatibility) I would have thought we have enough here to provide a set of guidelines to the dev community about when a release is either a major or minor. The missing piece here is how do we apply a branching strategy. I would suggest the same branching strategy that we would do under your suggestion of <major.patch>, so that the decision about a release being a major or a minor can be lazy made. It may be in practice that this starts off with every release being a major, as you have suggested, but we would keep the minor numbers and semver there to use when we see fit. If our practices improve, with the dev guidelines in place, we may see that releases become mostly minors. And I see this increases relevance if we introduce more SPIs into the codebase and have a bigger dev ecosystem around us, e.g. storage engine, compaction, indexes, thin-coordinators… Already today we know we have consumers of our maven artifacts, and dependency hell is a big part of semver's value, ref: https://semver.org/ > Why make a release at a fixed time each year? > > Stable-trunk is more popularly associated with Continuously Delivered > (CD) codebases > > We need to pick some points in time to provide stability/patch support > for, and an annual cadence provides some certainty to the community. > What we can do depends on how much time the community has to contribute. That is a changing and responsive thing. We can aim for an objective, and improve/streamline processes and guidelines. So, my suggestion is to… - keep semver, - we decide whether a release is major or minor when we agree to cut a release, and - that decision is primarily based on documented dev guidelines.
