[email protected] 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
http://accumulo.apache.org/governance/releasing.html:
<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 revision.
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 [mailto:[email protected]]
Sent: Saturday, December 06, 2014 1:43 PM
To: [email protected]
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.
[email protected] 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 [mailto:[email protected]] 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,<[email protected]> 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.
