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 Tue, 09 Dec 2014 00:00:59 GMT
Yes, that seems like a correct interpretation. However, to be clear, I do
not expect 1.7.0 will be ready before a new client API is added.


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

On Mon, Dec 8, 2014 at 6:54 PM, John Vines <vines@apache.org> wrote:

> 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