accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Vines <vi...@apache.org>
Subject Re: [DISCUSS] Semantic Versioning
Date Mon, 08 Dec 2014 23:54:58 GMT
Just to make sure I'm understanding this before we get into another vote
thread kerfluffle, if we adopt semver in 1.7.0, include a new client api in
1.7.0, deprecate the old api in 1.7.0, then semver would allow (but not
require) removing the deprecated api in 2.0.0, correct?

On Mon, Dec 8, 2014 at 6:21 PM, Christopher <ctubbsii@apache.org> wrote:

> 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