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:03:23 GMT
Also, I think the wording "adopt semver in 1.7.0" is an incorrect way of
thinking about it. What we'd do is adopt semver for future releases, and
the master branch would be bound to those guidelines. We wouldn't be
"adopting in 1.7.0", but adopting rules which determine what the next
version should be called.


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

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

> 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