accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dlmarion <>
Subject Re: [DISCUSS] Semantic Versioning
Date Sat, 06 Dec 2014 21:28:24 GMT
I am a strong proponent of deciding on something and starting it now, whatever that may be.
The status quo is not working as it has not been voted on and the rules are not very clear.
The discussions over the past few weeks are a good example of this. I think deciding on something
will answer a lot of questions that have been left unanswered. Backporting features, api compatibility,
deprecation, etc. If that means we rename 1.7 to make it easier, so be it. 

The only thing preventing us from adopting a new standard is ourselves.

Also, regarding abandoning the current API in favor of a new one is, IMO, not a wise choice.
I imagine a total of zero users in our userbase wanting us to force them to rewrite their
code. It will lead to a lot of backport requests for people that want/need new features but
cant upgrade. If we go down that route I would hope we let the users vote.

<div>-------- Original message --------</div><div>From: Josh Elser <>
</div><div>Date:12/06/2014  4:05 PM  (GMT-05:00) </div><div>To:
</div><div>Cc:  </div><div>Subject: Re: [DISCUSS] Semantic Versioning
</div>Ah, I was speaking more to the initial discussion on 3176 [1].

1.7.0 is already a major release though (given our current versioning) 
which would allow all of the current new features it has (good point on 
durability, I forgot about that one). Renaming 1.7.0 to 2.0.0 would also 
let us concurrently adopt semver properly. I don't think we *have* to 
change 1.7 to not be clear to users about compatibility, but doing so 
could be a good first step in a better compat statement (IMO).

Is that what you ultimately want to see here? I'm not positive if I'm 
just talking past you or if we're working towards something.

[1] wrote:
> Sorry, I don't see recent discussions[1,2] as pushing for increased compatibility guarantees.
Regarding digits in the version number, change 1.7 to 2.0 and it's done. That actually falls
in line with what is stated on the release page, as it says that major features will be in
a major release. IMO, replication is a major feature. Durability could be also.
> [1]
> [2]
> -----Original Message-----
> From: Josh Elser []
> Sent: Saturday, December 06, 2014 2:50 PM
> To:
> Subject: Re: [DISCUSS] Semantic Versioning
> wrote:
>>    From what I remember in the previous discussions on this topic, there was some
confusion as to what our current numbering scheme actually means. If we can't agree on it,
then our users have no guarantees. Semver, or whatever we agree on, is a contract between
each of us, and also between us and our users. Users will know the differences between our
versions and we will have guidance on where we are allowed to put changes.
> AFAIK, we are very clear in what our versioning means. From
> <snip>
> The intent is for all major features to be implemented in a major release, with only
bug fixes and minor features being included in minor releases. API changes should only be
made on major releases, with continued support of the previous API for at least one major
> This will give user code a major revision to convert from the old API to the new API.
> </snip>
> The recent discussions have been pushes for *increased* compatibility guarantees over
what we currently have in writing.
>> IMO, version numbers mean something. I personally don't care what the version number
is, but depending on which digit is different between the version I am using and the current
version number, I know whether or not I need to change my code.
> Right. My point was, if we adopt semver for 1.x, we don't have enough digits to define
bugfix, minor and major releases.
>> Some of us seem hung up on version 2.0 for a new client api. Why? How long will it
take to define and agree on an api, then develop it and test it. What does that mean for features
that are ready to go in the mean time? There is no reason that a new client api cannot be
released in versions 3, 4, 5, or later. Likewise, there is no reason that we can't release
master as 2.0 right now and remove things that are already deprecated (Aggregator) and include
new major features (replication).
> You use "hung up", but that's what we agreed on for the upcoming releases (replication+htrace
already in 1.7, new client API in 2.0). If we want to change that, we should just decide to.
This seems to be a likely decision to make.
>>    I see no issue with changing the numbering now, especially since we there is no
agreement on what it means. It leads to discussions like the one in the 3176 thread.
>> -----Original Message-----
>> From: Josh Elser []
>> Sent: Saturday, December 06, 2014 1:43 PM
>> To:
>> Subject: Re: [DISCUSS] Semantic Versioning
>> Personally, I'm worried that trying to apply semver on top of 1.x as a whole is going
to lead to more problems because we don't have 3 version "bits" to play with like semver expects.
That was a big reason why we were going to align semver with 2.0.0 in the first place, IIRC.
>> wrote:
>>> Christopher had asked for informal votes on, "releases [+1]:  start operating
under whatever rules we adopt as of the master branch," which to me means if we approve we
adopt immediately. IMO, putting off this decision is hurting us, see the other threads over
the past week. I don't believe that adopting semver now and applying it to 1.6.x and beyond
hurts us in any way.
>>> -----Original Message-----
>>> From: John Vines [] Sent:Saturday, December
>>> 06,
>>> 2014 1:19 PM
>>> To: Accumulo Dev List
>>> Subject: Re: [DISCUSS] Semantic Versioning
>>> I think there's an issue with this course of discussion because we're discussion
issues of our current 1.x release style while also discussion Semver, both of which are incongruent
with one another. Perhaps we need to segregate adopting semver for 2.0.0 (which is waht I
assumed), vs. adopting semver for our next release vs. adopting semver for some release after
the next but before 2.0.0?
>>> On Sat, Dec 6, 2014 at 1:16 PM,<>    wrote:
>>>>>    " This basically represents a goal to not to add new APIs without
>>>>> bumping the minor release."
>>>>>      I didn't think that with semver you could change the API in a
>>>>> patch  release. An API change, if backwards compatible, requires a
>>>>> new MINOR  release. Am I reading 6, 7, 8 and in the specification
>>>>> incorrectly? I  might need an example.
>> Yeah, you're right, Dave. Just re-read this myself. There is no concern of how APIs
are changed in a patch/bugfix release because they are disallowed by definition.
>> The only way I would see this relevant is if we didn't adopt semver for this awkward
[1.7.0,2.0.0) version range.
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message