accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Marion <dmario...@gmail.com>
Subject Re: [DISCUSS] Semantic Versioning
Date Mon, 08 Dec 2014 23:29:11 GMT
+1
On Dec 8, 2014 6:22 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