accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Semantic Versioning
Date Mon, 08 Dec 2014 23:21:57 GMT
Short Summary:

I see 6 informal +1s (including my own) for adopting Semver, and no -1s.
Other points differ.

Longer Summary:

Including additional strictness for deprecation documented in a major
release does not have significant consensus and, in hindsight, probably
doesn't really add much value. Semver does not bind us to a particular
release cycle for major/minor/bugfix, only what we call it when we make
certain changes. The basic Semver rules are sufficient.

Including additional strictness for forward compatibility isn't necessary.
Semver requires a minor version bump if new features are added to the API.
So, this is redundant and not needed.

Including the wire version is tough without a test framework, and maybe
unnecessary, since the main concern about compatibility seems to be with
applications needing to be modified to function with a newer client
library, which contains the RPC code. If we ensure compatibility at the
API, then users simply need to drop in the appropriate client jars for wire
compatibility. This is probably sufficient.

There seems to be some confusion about when and where these rules are
applied. However, I believe we can go ahead and start adopting these rules
from here on, without any issues. This doesn't hurt users, and only *adds*
to the stability of the API, which we've already been striving for. It also
doesn't bind us to a particular release cycle or deprecation duration. It
only helps us determine what minimum version we should call something, when
we do release. Upon adoption, the "master" branch version can be computed
from the rules. If that computation requires a bump higher than what we are
comfortable with, we can always ensure a greater level of compatibility
than what currently exists, in order to avoid that bump, if we so choose.
Adoption of these rules should help inform such discussions.

Now, to be clear, it may be the case that the 1.5 and 1.6 maintenance
branches already have introduced additional APIs that under Semver would
have required a minor version bump. I'm not suggesting that we revert those
changes, but by adopting the Semver, we can agree to avoid doing that from
here on. Since 1.7 already adds additional features, by adopting Semver, we
simply agree that the master branch should be called 2.0 if it is not
backwards-compatible with 1.6.x, and 1.7.0 if it is. Adopting these rules
helps inform that decision, but does not make that decision for us. Either
way, that decision would be independent of adopting Semver today for all
future releases. Incidentally, this answers the question of whether 2.0 can
introduce "breaking" (removal of deprecations) changes, but it does not say
that we must stop support for 1.x or release 2.0 on any particular timeline.

Action:

In the absence of further discussion, I think we should call a majority
vote (tomorrow) to adopt Semver, so we can immediately start communicating
better versioning semantics, and we can make progress with a concrete
decision to help with release planning. The specific wording of the
proposition I would suggest (please propose amendments here if you think it
is unclear) would be:

"Vote to adopt Semantic Versioning 2.0.0 (as described at https://semver.org)
from this point forward, for all future releases, with the public API
documented in the README."

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message