accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: [DISCUSS] Semantic Versioning
Date Sat, 06 Dec 2014 19:40:43 GMT
>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.

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.

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).

 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
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
> -----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.

View raw message