accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Josh Elser <els...@apache.org>
Subject Re: [DISCUSS] Semantic Versioning
Date Tue, 09 Dec 2014 17:24:44 GMT
This sounds good. Looking forward to a vote on this. Thanks, Christopher.

Christopher wrote:
> 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
View raw message