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:01:25 GMT
Ack! My clarity failed: I *DO* expect 1.7.0 to be ready before a new client
API is added.


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

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

> 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