For a minor/major? I can imagine doing this for a patch version, but this is of
much less importance to downstream users.
Do you have any examples of projects that do this for major/minor development
branches, as you propose?
I'm just a bit confused about the proposition to decouple from releases, when
the whole point of semver is that it's a public API that we honour around
compatibility, so it is sort of intrinsically coupled to releases. It just
sounds like a way to make our lives more complicated too, as it's less clear
what releases are actually extant.
On 03/05/2021, 11:31, "Mick Semb Wever" <m...@apache.org> wrote:
> > Vendors are also free to support and provide hot-fixes and back ports
on these unreleased versions, outside of the community's efforts or concerns
>
> This seems to me like we're endorsing the release of these versions by
downstream maintainers? Even if we decide to modify this proposal and say "no,
we don't endorse that," how do we prevent it?
>
We have to be explicit that semantic versioning != releases. That only
some version numbers get formal releases attached to them. And only
some of those releases get release branches to them. That is, we are
separating the concerns of versioning and releases for dev community
benefit.
I know some Apache projects don't do takeX re-votes on repeated
release attempts. Instead they fix the problem (that caused the vote
to fail), increment the version, and start a new vote on a new release
with a new version. These projects then have versions that are never
released, though this example is not to do with semver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
