[DISCUSS] Semantic Versioning

[Christopher <ct...@apache.org>]

I don't want to issue another vote right now, but I just (re-read) the
semantic versioning 2.0.0 document (http://semver.org/), and I think we
should just go ahead and adopt it and start abiding by it.

In addition, I'd also like to ensure we provide some long-term stability
for deprecations. Semver only says we should have at least 1 minor release
with the deprecation documented. I think we should have at least one
(typically: exactly one) major release with the deprecation documented,
before breaking it in the next major release after that.

Also, Semver also does not say anything about forward-compatibility, but I
think we do probably want to ensure forward compatibility between "patch"
releases (aka "bugfix" releases), in addition to backwards-compatibility. I
don't think it would make sense to add forward-compatibility to "minor"
releases, though, because that would prevent adding non-breaking features,
and that's the explicit purpose of Semver's "minor" releases.

We've previously discussed versioning semantics, but never came to a
decision. I recall that there was some views that we should defer applying
these semantics until after 2.0 (that position was used to justify several
backports). However, given the stronger concerns more recently, regarding
API stability, it appears as though those views are different now, and
maybe we should just start applying this from 1.7 and forward.

Semver with these two additions (forward-compatibility for patch releases,
and longer-deprecation cycle), basically encompasses the guidelines that I
suggested in the last [VOTE] thread about what to do between 1.7.0 and
2.0.0, and also clarifies what I was thinking in terms of deprecations in
2.0. If we adopt this, that thread is essentially moot.

Thoughts? Are there any additions we'd like to see? Strong statements that
go beyond semver? Should we just vote on this?

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

Re: [DISCUSS] Semantic Versioning

[Christopher <ct...@apache.org>]

On my first few readings, I felt it was a bit ambiguous, and wanted to make
it more clear. It may not be needed to add that language.


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

On Sat, Dec 6, 2014 at 1:16 PM, <dl...@comcast.net> 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.
>
> -----Original Message-----
> From: Christopher [mailto:ctubbsii@apache.org]
> Sent: Saturday, December 06, 2014 12:53 PM
> To: Accumulo Dev List
> Subject: Re: [DISCUSS] Semantic Versioning
>
> On Sat, Dec 6, 2014 at 9:55 AM, <dl...@comcast.net> wrote:
>
> > [+1 ]: adopt semver 2.0.0 (http://semver.org)
> > [0 ]: adopt additional strictness to require documenting deprecation
> > for at least 1 major release before possible to consider in the next
> > major release
> > [* ]: adopt additional strictness to ensure forward compatibility
> > between bugfix releases [ +1]: start operating under whatever rules we
> > adopt as of the master branch
> > [** ]: keep the master branch named 1.7.0 [ +1***]: define scope of
> > these versioning compatibility rules to  be our current definition of
> > "public API" and the wire version
> >
> > * I'm confused by this. A change in 1.6.1 is forward compatible until
> > it's not. If a patch is applied to 1.6.2 that is not backwards
> > compatible, then that version is not 1.6.2, it's 1.7.0.
> >
>
> This basically represents a goal to not to add new APIs without bumping
> the minor release. That way, code written against 1.6.2 would run against a
> 1.6.1 instance.
>
>
> > ** if we vote to start operating under these rules, then the version
> > should calculated when development is done.
> >
>
> It can be, yes... but we can also ensure we don't have any removals that
> would force the calculation to bump higher than we want it to be. Keeping
> the master branch 1.7 means that we fix the calculation.
>
>
> > *** where is the current definition documented?
> >
> >
> The README
>
>
> > -----Original Message-----
> > From: Christopher [mailto:ctubbsii@apache.org]
> > Sent: Friday, December 05, 2014 1:46 PM
> > To: Accumulo Dev List
> > Subject: Re: [DISCUSS] Semantic Versioning
> >
> > It would be helpful to this thread, if we can get some informal votes
> > on the following propositions:
> >
> > [ ]: adopt semver 2.0.0 (http://semver.org) [ ]: adopt additional
> > strictness to require documenting deprecation for at least 1 major
> > release before possible to consider in the next major release [ ]:
> > adopt additional strictness to ensure forward compatibility between
> bugfix releases [ ]:
> > start operating under whatever rules we adopt as of the master branch [
> ]:
> > keep the master branch named 1.7.0 [ ]: define scope of these
> > versioning compatibility rules to  be our current definition of
> > "public API" and the wire version
> >
> > I'm going to assume it's a given that if any exceptional situations
> > arise, we'll handle those through further discussions/voting, as
> appropriate.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com> wrote:
> >
> > > Christopher wrote:
> > >
> > >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
> > >>
> > >>  >  +1 to semver
> > >>> >  +1 to 1 major release before removing deprecated items
> > >>> >  +1 to forward compatibility between bugfix releases
> > >>> >
> > >>> >  What's the version # for the master branch if these rules are
> > applied?
> > >>> >
> > >>> >
> > >>>
> > >> Well, I'd say1.7  still, since it is consistent with our existing
> > >> rules for determining a "major" releasetoday,  *and*  it matches
> > >> semver definition of a "minor" release, because it doesn't break
> > >> backwards-compatibility compatibility from1.6  (with one tiny
> > >> exception of dropping Instance.getConfiguration()... because it was
> > >> an exceptional situation discussed in previous threads; if people
> > >> are uncomfortable with that exception, I can return it to the API,
> > >> if it helps achieve consensus here).
> > >>
> > >>
> > > Sounds right to me.
> > >
> > > When we actually have code to land in Apache for 2.0.0, I figured
> > > we'd break 1.7.X off to branch named "1.7" and master would become
> 2.0.0.
> > > We can have some feature branch in Apache off to the side to make
> > > sure
> > > 2.0.0 development can happen in a shared environment before making
> > > the above switch.
> > >
> >
> >
>
>

Re: [DISCUSS] Semantic Versioning

[Christopher <ct...@apache.org>]

I disagree that our current practices are incongruent with semver. We've
already made efforts to retain backwards compatibility in the last several
releases, and that's all that is necessary for a semver minor release. The
only issue is whether we should drop deprecated APIs in 1.7.0. If yes, and
we've adopted semver, all that means is that we release what is currently
in the master branch as 2.0.0 instead. If no, then it can still be 1.7.0
under semver.

I agree with Dave Marion that we're hurting not having strict API
compatibility guidelines for 1.x and post-poning it to 2.0.0. What I think
we need is to stop running around in circles, adopt some guidelines, and
then decide what we want to call the version based on the guidelines. We
should let the guidelines we adopt direct our release activity, rather than
let our release activity arbitrarily bind us to complicated unclear
guidelines.

So far, it seems like everybody's opinions are all over the place and we're
not really making progress on a decision. I think we should call a vote
soon, on adopting semver immediately (without my suggested alterations,
which I no longer feel are necessary), and committing to those guidelines
for all future releases immediately, and let that inform our release naming
and direct conversations about what should or shouldn't be included in a
release. If those guidelines do not prove to be useful, we can amend later.
But I think we could use some clarity now.


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

On Sat, Dec 6, 2014 at 1:19 PM, John Vines <vi...@apache.org> wrote:

> 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, <dl...@comcast.net> 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.
> >
> > -----Original Message-----
> > From: Christopher [mailto:ctubbsii@apache.org]
> > Sent: Saturday, December 06, 2014 12:53 PM
> > To: Accumulo Dev List
> > Subject: Re: [DISCUSS] Semantic Versioning
> >
> > On Sat, Dec 6, 2014 at 9:55 AM, <dl...@comcast.net> wrote:
> >
> > > [+1 ]: adopt semver 2.0.0 (http://semver.org)
> > > [0 ]: adopt additional strictness to require documenting deprecation
> > > for at least 1 major release before possible to consider in the next
> > > major release
> > > [* ]: adopt additional strictness to ensure forward compatibility
> > > between bugfix releases [ +1]: start operating under whatever rules we
> > > adopt as of the master branch
> > > [** ]: keep the master branch named 1.7.0 [ +1***]: define scope of
> > > these versioning compatibility rules to  be our current definition of
> > > "public API" and the wire version
> > >
> > > * I'm confused by this. A change in 1.6.1 is forward compatible until
> > > it's not. If a patch is applied to 1.6.2 that is not backwards
> > > compatible, then that version is not 1.6.2, it's 1.7.0.
> > >
> >
> > This basically represents a goal to not to add new APIs without bumping
> > the minor release. That way, code written against 1.6.2 would run
> against a
> > 1.6.1 instance.
> >
> >
> > > ** if we vote to start operating under these rules, then the version
> > > should calculated when development is done.
> > >
> >
> > It can be, yes... but we can also ensure we don't have any removals that
> > would force the calculation to bump higher than we want it to be. Keeping
> > the master branch 1.7 means that we fix the calculation.
> >
> >
> > > *** where is the current definition documented?
> > >
> > >
> > The README
> >
> >
> > > -----Original Message-----
> > > From: Christopher [mailto:ctubbsii@apache.org]
> > > Sent: Friday, December 05, 2014 1:46 PM
> > > To: Accumulo Dev List
> > > Subject: Re: [DISCUSS] Semantic Versioning
> > >
> > > It would be helpful to this thread, if we can get some informal votes
> > > on the following propositions:
> > >
> > > [ ]: adopt semver 2.0.0 (http://semver.org) [ ]: adopt additional
> > > strictness to require documenting deprecation for at least 1 major
> > > release before possible to consider in the next major release [ ]:
> > > adopt additional strictness to ensure forward compatibility between
> > bugfix releases [ ]:
> > > start operating under whatever rules we adopt as of the master branch [
> > ]:
> > > keep the master branch named 1.7.0 [ ]: define scope of these
> > > versioning compatibility rules to  be our current definition of
> > > "public API" and the wire version
> > >
> > > I'm going to assume it's a given that if any exceptional situations
> > > arise, we'll handle those through further discussions/voting, as
> > appropriate.
> > >
> > >
> > > --
> > > Christopher L Tubbs II
> > > http://gravatar.com/ctubbsii
> > >
> > > On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com>
> wrote:
> > >
> > > > Christopher wrote:
> > > >
> > > >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
> > > >>
> > > >>  >  +1 to semver
> > > >>> >  +1 to 1 major release before removing deprecated items
> > > >>> >  +1 to forward compatibility between bugfix releases
> > > >>> >
> > > >>> >  What's the version # for the master branch if these rules are
> > > applied?
> > > >>> >
> > > >>> >
> > > >>>
> > > >> Well, I'd say1.7  still, since it is consistent with our existing
> > > >> rules for determining a "major" releasetoday,  *and*  it matches
> > > >> semver definition of a "minor" release, because it doesn't break
> > > >> backwards-compatibility compatibility from1.6  (with one tiny
> > > >> exception of dropping Instance.getConfiguration()... because it was
> > > >> an exceptional situation discussed in previous threads; if people
> > > >> are uncomfortable with that exception, I can return it to the API,
> > > >> if it helps achieve consensus here).
> > > >>
> > > >>
> > > > Sounds right to me.
> > > >
> > > > When we actually have code to land in Apache for 2.0.0, I figured
> > > > we'd break 1.7.X off to branch named "1.7" and master would become
> > 2.0.0.
> > > > We can have some feature branch in Apache off to the side to make
> > > > sure
> > > > 2.0.0 development can happen in a shared environment before making
> > > > the above switch.
> > > >
> > >
> > >
> >
> >
>

Re: [DISCUSS] Semantic Versioning

[Josh Elser <jo...@gmail.com>]

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] 
http://mail-archives.apache.org/mod_mbox/accumulo-dev/201412.mbox/%3CCAOyNEs6E%3DkGDyC_NOfnqNitSdnJ%2BYcBtg9AuYJ1BC%2BoexwHDVw%40mail.gmail.com%3E

dlmarion@comcast.net 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] http://mail-archives.apache.org/mod_mbox/accumulo-dev/201412.mbox/%3CCADczPYRW-WnSnSd5YHm7cD%2BZR6WB7LM9F8uiMbDnzn2vben%2Bpg%40mail.gmail.com%3E
> [2] http://mail-archives.apache.org/mod_mbox/accumulo-dev/201412.mbox/%3CCADczPYTYwftJt%3D6FC8a_-cAL0hd6ZZx%3D9OznPnG6afuQjuKwUQ%40mail.gmail.com%3E
>
>
>
> -----Original Message-----
> From: Josh Elser [mailto:josh.elser@gmail.com]
> Sent: Saturday, December 06, 2014 2:50 PM
> To: dev@accumulo.apache.org
> Subject: Re: [DISCUSS] Semantic Versioning
>
> dlmarion@comcast.net 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:josh.elser@gmail.com]
>> Sent: Saturday, December 06, 2014 1:43 PM
>> To: dev@accumulo.apache.org
>> 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.
>>
>> dlmarion@comcast.net 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:vines@apache.org] 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,<dl...@comcast.net>    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.
>>
>

RE: [DISCUSS] Semantic Versioning

[dl...@comcast.net]

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] http://mail-archives.apache.org/mod_mbox/accumulo-dev/201412.mbox/%3CCADczPYRW-WnSnSd5YHm7cD%2BZR6WB7LM9F8uiMbDnzn2vben%2Bpg%40mail.gmail.com%3E
[2] http://mail-archives.apache.org/mod_mbox/accumulo-dev/201412.mbox/%3CCADczPYTYwftJt%3D6FC8a_-cAL0hd6ZZx%3D9OznPnG6afuQjuKwUQ%40mail.gmail.com%3E



-----Original Message-----
From: Josh Elser [mailto:josh.elser@gmail.com] 
Sent: Saturday, December 06, 2014 2:50 PM
To: dev@accumulo.apache.org
Subject: Re: [DISCUSS] Semantic Versioning

dlmarion@comcast.net 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:josh.elser@gmail.com]
> Sent: Saturday, December 06, 2014 1:43 PM
> To: dev@accumulo.apache.org
> 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.
>
> dlmarion@comcast.net 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:vines@apache.org] 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,<dl...@comcast.net>   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.
>

Re: [DISCUSS] Semantic Versioning

[Josh Elser <jo...@gmail.com>]

dlmarion@comcast.net 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:josh.elser@gmail.com]
> Sent: Saturday, December 06, 2014 1:43 PM
> To: dev@accumulo.apache.org
> 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.
>
> dlmarion@comcast.net 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:vines@apache.org] 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,<dl...@comcast.net>   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.
>

RE: [DISCUSS] Semantic Versioning

[dl...@comcast.net]

>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 [mailto:josh.elser@gmail.com] 
Sent: Saturday, December 06, 2014 1:43 PM
To: dev@accumulo.apache.org
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.

dlmarion@comcast.net 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:vines@apache.org] 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,<dl...@comcast.net>  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.

RE: [DISCUSS] Semantic Versioning

[dl...@comcast.net]

Sorry, bad copy/paste job there, should be " start operating under whatever rules we adopt as of the master branch"

-----Original Message-----
From: dlmarion@comcast.net [mailto:dlmarion@comcast.net] 
Sent: Saturday, December 06, 2014 1:34 PM
To: dev@accumulo.apache.org
Subject: RE: [DISCUSS] Semantic Versioning

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:vines@apache.org]
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, <dl...@comcast.net> 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.
>
> -----Original Message-----
> From: Christopher [mailto:ctubbsii@apache.org]
> Sent: Saturday, December 06, 2014 12:53 PM
> To: Accumulo Dev List
> Subject: Re: [DISCUSS] Semantic Versioning
>
> On Sat, Dec 6, 2014 at 9:55 AM, <dl...@comcast.net> wrote:
>
> > [+1 ]: adopt semver 2.0.0 (http://semver.org)
> > [0 ]: adopt additional strictness to require documenting deprecation 
> > for at least 1 major release before possible to consider in the next 
> > major release
> > [* ]: adopt additional strictness to ensure forward compatibility 
> > between bugfix releases [ +1]: start operating under whatever rules 
> > we adopt as of the master branch
> > [** ]: keep the master branch named 1.7.0 [ +1***]: define scope of 
> > these versioning compatibility rules to  be our current definition 
> > of "public API" and the wire version
> >
> > * I'm confused by this. A change in 1.6.1 is forward compatible 
> > until it's not. If a patch is applied to 1.6.2 that is not backwards 
> > compatible, then that version is not 1.6.2, it's 1.7.0.
> >
>
> This basically represents a goal to not to add new APIs without 
> bumping the minor release. That way, code written against 1.6.2 would 
> run against a
> 1.6.1 instance.
>
>
> > ** if we vote to start operating under these rules, then the version 
> > should calculated when development is done.
> >
>
> It can be, yes... but we can also ensure we don't have any removals 
> that would force the calculation to bump higher than we want it to be.
> Keeping the master branch 1.7 means that we fix the calculation.
>
>
> > *** where is the current definition documented?
> >
> >
> The README
>
>
> > -----Original Message-----
> > From: Christopher [mailto:ctubbsii@apache.org]
> > Sent: Friday, December 05, 2014 1:46 PM
> > To: Accumulo Dev List
> > Subject: Re: [DISCUSS] Semantic Versioning
> >
> > It would be helpful to this thread, if we can get some informal 
> > votes on the following propositions:
> >
> > [ ]: adopt semver 2.0.0 (http://semver.org) [ ]: adopt additional 
> > strictness to require documenting deprecation for at least 1 major 
> > release before possible to consider in the next major release [ ]:
> > adopt additional strictness to ensure forward compatibility between
> bugfix releases [ ]:
> > start operating under whatever rules we adopt as of the master 
> > branch [
> ]:
> > keep the master branch named 1.7.0 [ ]: define scope of these 
> > versioning compatibility rules to  be our current definition of 
> > "public API" and the wire version
> >
> > I'm going to assume it's a given that if any exceptional situations 
> > arise, we'll handle those through further discussions/voting, as
> appropriate.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com> wrote:
> >
> > > Christopher wrote:
> > >
> > >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
> > >>
> > >>  >  +1 to semver
> > >>> >  +1 to 1 major release before removing deprecated items
> > >>> >  +1 to forward compatibility between bugfix releases
> > >>> >
> > >>> >  What's the version # for the master branch if these rules are
> > applied?
> > >>> >
> > >>> >
> > >>>
> > >> Well, I'd say1.7  still, since it is consistent with our existing 
> > >> rules for determining a "major" releasetoday,  *and*  it matches 
> > >> semver definition of a "minor" release, because it doesn't break 
> > >> backwards-compatibility compatibility from1.6  (with one tiny 
> > >> exception of dropping Instance.getConfiguration()... because it 
> > >> was an exceptional situation discussed in previous threads; if 
> > >> people are uncomfortable with that exception, I can return it to 
> > >> the API, if it helps achieve consensus here).
> > >>
> > >>
> > > Sounds right to me.
> > >
> > > When we actually have code to land in Apache for 2.0.0, I figured 
> > > we'd break 1.7.X off to branch named "1.7" and master would become
> 2.0.0.
> > > We can have some feature branch in Apache off to the side to make 
> > > sure
> > > 2.0.0 development can happen in a shared environment before making 
> > > the above switch.
> > >
> >
> >
>
>

Re: [DISCUSS] Semantic Versioning

[Josh Elser <jo...@gmail.com>]

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.

dlmarion@comcast.net 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:vines@apache.org]
> 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,<dl...@comcast.net>  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.

RE: [DISCUSS] Semantic Versioning

[dl...@comcast.net]

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:vines@apache.org] 
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, <dl...@comcast.net> 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.
>
> -----Original Message-----
> From: Christopher [mailto:ctubbsii@apache.org]
> Sent: Saturday, December 06, 2014 12:53 PM
> To: Accumulo Dev List
> Subject: Re: [DISCUSS] Semantic Versioning
>
> On Sat, Dec 6, 2014 at 9:55 AM, <dl...@comcast.net> wrote:
>
> > [+1 ]: adopt semver 2.0.0 (http://semver.org)
> > [0 ]: adopt additional strictness to require documenting deprecation 
> > for at least 1 major release before possible to consider in the next 
> > major release
> > [* ]: adopt additional strictness to ensure forward compatibility 
> > between bugfix releases [ +1]: start operating under whatever rules 
> > we adopt as of the master branch
> > [** ]: keep the master branch named 1.7.0 [ +1***]: define scope of 
> > these versioning compatibility rules to  be our current definition 
> > of "public API" and the wire version
> >
> > * I'm confused by this. A change in 1.6.1 is forward compatible 
> > until it's not. If a patch is applied to 1.6.2 that is not backwards 
> > compatible, then that version is not 1.6.2, it's 1.7.0.
> >
>
> This basically represents a goal to not to add new APIs without 
> bumping the minor release. That way, code written against 1.6.2 would 
> run against a
> 1.6.1 instance.
>
>
> > ** if we vote to start operating under these rules, then the version 
> > should calculated when development is done.
> >
>
> It can be, yes... but we can also ensure we don't have any removals 
> that would force the calculation to bump higher than we want it to be. 
> Keeping the master branch 1.7 means that we fix the calculation.
>
>
> > *** where is the current definition documented?
> >
> >
> The README
>
>
> > -----Original Message-----
> > From: Christopher [mailto:ctubbsii@apache.org]
> > Sent: Friday, December 05, 2014 1:46 PM
> > To: Accumulo Dev List
> > Subject: Re: [DISCUSS] Semantic Versioning
> >
> > It would be helpful to this thread, if we can get some informal 
> > votes on the following propositions:
> >
> > [ ]: adopt semver 2.0.0 (http://semver.org) [ ]: adopt additional 
> > strictness to require documenting deprecation for at least 1 major 
> > release before possible to consider in the next major release [ ]:
> > adopt additional strictness to ensure forward compatibility between
> bugfix releases [ ]:
> > start operating under whatever rules we adopt as of the master 
> > branch [
> ]:
> > keep the master branch named 1.7.0 [ ]: define scope of these 
> > versioning compatibility rules to  be our current definition of 
> > "public API" and the wire version
> >
> > I'm going to assume it's a given that if any exceptional situations 
> > arise, we'll handle those through further discussions/voting, as
> appropriate.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com> wrote:
> >
> > > Christopher wrote:
> > >
> > >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
> > >>
> > >>  >  +1 to semver
> > >>> >  +1 to 1 major release before removing deprecated items
> > >>> >  +1 to forward compatibility between bugfix releases
> > >>> >
> > >>> >  What's the version # for the master branch if these rules are
> > applied?
> > >>> >
> > >>> >
> > >>>
> > >> Well, I'd say1.7  still, since it is consistent with our existing 
> > >> rules for determining a "major" releasetoday,  *and*  it matches 
> > >> semver definition of a "minor" release, because it doesn't break 
> > >> backwards-compatibility compatibility from1.6  (with one tiny 
> > >> exception of dropping Instance.getConfiguration()... because it 
> > >> was an exceptional situation discussed in previous threads; if 
> > >> people are uncomfortable with that exception, I can return it to 
> > >> the API, if it helps achieve consensus here).
> > >>
> > >>
> > > Sounds right to me.
> > >
> > > When we actually have code to land in Apache for 2.0.0, I figured 
> > > we'd break 1.7.X off to branch named "1.7" and master would become
> 2.0.0.
> > > We can have some feature branch in Apache off to the side to make 
> > > sure
> > > 2.0.0 development can happen in a shared environment before making 
> > > the above switch.
> > >
> >
> >
>
>

Re: [DISCUSS] Semantic Versioning

[John Vines <vi...@apache.org>]

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, <dl...@comcast.net> 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.
>
> -----Original Message-----
> From: Christopher [mailto:ctubbsii@apache.org]
> Sent: Saturday, December 06, 2014 12:53 PM
> To: Accumulo Dev List
> Subject: Re: [DISCUSS] Semantic Versioning
>
> On Sat, Dec 6, 2014 at 9:55 AM, <dl...@comcast.net> wrote:
>
> > [+1 ]: adopt semver 2.0.0 (http://semver.org)
> > [0 ]: adopt additional strictness to require documenting deprecation
> > for at least 1 major release before possible to consider in the next
> > major release
> > [* ]: adopt additional strictness to ensure forward compatibility
> > between bugfix releases [ +1]: start operating under whatever rules we
> > adopt as of the master branch
> > [** ]: keep the master branch named 1.7.0 [ +1***]: define scope of
> > these versioning compatibility rules to  be our current definition of
> > "public API" and the wire version
> >
> > * I'm confused by this. A change in 1.6.1 is forward compatible until
> > it's not. If a patch is applied to 1.6.2 that is not backwards
> > compatible, then that version is not 1.6.2, it's 1.7.0.
> >
>
> This basically represents a goal to not to add new APIs without bumping
> the minor release. That way, code written against 1.6.2 would run against a
> 1.6.1 instance.
>
>
> > ** if we vote to start operating under these rules, then the version
> > should calculated when development is done.
> >
>
> It can be, yes... but we can also ensure we don't have any removals that
> would force the calculation to bump higher than we want it to be. Keeping
> the master branch 1.7 means that we fix the calculation.
>
>
> > *** where is the current definition documented?
> >
> >
> The README
>
>
> > -----Original Message-----
> > From: Christopher [mailto:ctubbsii@apache.org]
> > Sent: Friday, December 05, 2014 1:46 PM
> > To: Accumulo Dev List
> > Subject: Re: [DISCUSS] Semantic Versioning
> >
> > It would be helpful to this thread, if we can get some informal votes
> > on the following propositions:
> >
> > [ ]: adopt semver 2.0.0 (http://semver.org) [ ]: adopt additional
> > strictness to require documenting deprecation for at least 1 major
> > release before possible to consider in the next major release [ ]:
> > adopt additional strictness to ensure forward compatibility between
> bugfix releases [ ]:
> > start operating under whatever rules we adopt as of the master branch [
> ]:
> > keep the master branch named 1.7.0 [ ]: define scope of these
> > versioning compatibility rules to  be our current definition of
> > "public API" and the wire version
> >
> > I'm going to assume it's a given that if any exceptional situations
> > arise, we'll handle those through further discussions/voting, as
> appropriate.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com> wrote:
> >
> > > Christopher wrote:
> > >
> > >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
> > >>
> > >>  >  +1 to semver
> > >>> >  +1 to 1 major release before removing deprecated items
> > >>> >  +1 to forward compatibility between bugfix releases
> > >>> >
> > >>> >  What's the version # for the master branch if these rules are
> > applied?
> > >>> >
> > >>> >
> > >>>
> > >> Well, I'd say1.7  still, since it is consistent with our existing
> > >> rules for determining a "major" releasetoday,  *and*  it matches
> > >> semver definition of a "minor" release, because it doesn't break
> > >> backwards-compatibility compatibility from1.6  (with one tiny
> > >> exception of dropping Instance.getConfiguration()... because it was
> > >> an exceptional situation discussed in previous threads; if people
> > >> are uncomfortable with that exception, I can return it to the API,
> > >> if it helps achieve consensus here).
> > >>
> > >>
> > > Sounds right to me.
> > >
> > > When we actually have code to land in Apache for 2.0.0, I figured
> > > we'd break 1.7.X off to branch named "1.7" and master would become
> 2.0.0.
> > > We can have some feature branch in Apache off to the side to make
> > > sure
> > > 2.0.0 development can happen in a shared environment before making
> > > the above switch.
> > >
> >
> >
>
>

RE: [DISCUSS] Semantic Versioning

[dl...@comcast.net]

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

-----Original Message-----
From: Christopher [mailto:ctubbsii@apache.org] 
Sent: Saturday, December 06, 2014 12:53 PM
To: Accumulo Dev List
Subject: Re: [DISCUSS] Semantic Versioning

On Sat, Dec 6, 2014 at 9:55 AM, <dl...@comcast.net> wrote:

> [+1 ]: adopt semver 2.0.0 (http://semver.org)
> [0 ]: adopt additional strictness to require documenting deprecation 
> for at least 1 major release before possible to consider in the next 
> major release
> [* ]: adopt additional strictness to ensure forward compatibility 
> between bugfix releases [ +1]: start operating under whatever rules we 
> adopt as of the master branch
> [** ]: keep the master branch named 1.7.0 [ +1***]: define scope of 
> these versioning compatibility rules to  be our current definition of 
> "public API" and the wire version
>
> * I'm confused by this. A change in 1.6.1 is forward compatible until 
> it's not. If a patch is applied to 1.6.2 that is not backwards 
> compatible, then that version is not 1.6.2, it's 1.7.0.
>

This basically represents a goal to not to add new APIs without bumping the minor release. That way, code written against 1.6.2 would run against a
1.6.1 instance.


> ** if we vote to start operating under these rules, then the version 
> should calculated when development is done.
>

It can be, yes... but we can also ensure we don't have any removals that would force the calculation to bump higher than we want it to be. Keeping the master branch 1.7 means that we fix the calculation.


> *** where is the current definition documented?
>
>
The README


> -----Original Message-----
> From: Christopher [mailto:ctubbsii@apache.org]
> Sent: Friday, December 05, 2014 1:46 PM
> To: Accumulo Dev List
> Subject: Re: [DISCUSS] Semantic Versioning
>
> It would be helpful to this thread, if we can get some informal votes 
> on the following propositions:
>
> [ ]: adopt semver 2.0.0 (http://semver.org) [ ]: adopt additional 
> strictness to require documenting deprecation for at least 1 major 
> release before possible to consider in the next major release [ ]: 
> adopt additional strictness to ensure forward compatibility between bugfix releases [ ]:
> start operating under whatever rules we adopt as of the master branch [ ]:
> keep the master branch named 1.7.0 [ ]: define scope of these 
> versioning compatibility rules to  be our current definition of 
> "public API" and the wire version
>
> I'm going to assume it's a given that if any exceptional situations 
> arise, we'll handle those through further discussions/voting, as appropriate.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > Christopher wrote:
> >
> >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
> >>
> >>  >  +1 to semver
> >>> >  +1 to 1 major release before removing deprecated items
> >>> >  +1 to forward compatibility between bugfix releases
> >>> >
> >>> >  What's the version # for the master branch if these rules are
> applied?
> >>> >
> >>> >
> >>>
> >> Well, I'd say1.7  still, since it is consistent with our existing 
> >> rules for determining a "major" releasetoday,  *and*  it matches 
> >> semver definition of a "minor" release, because it doesn't break 
> >> backwards-compatibility compatibility from1.6  (with one tiny 
> >> exception of dropping Instance.getConfiguration()... because it was 
> >> an exceptional situation discussed in previous threads; if people 
> >> are uncomfortable with that exception, I can return it to the API, 
> >> if it helps achieve consensus here).
> >>
> >>
> > Sounds right to me.
> >
> > When we actually have code to land in Apache for 2.0.0, I figured 
> > we'd break 1.7.X off to branch named "1.7" and master would become 2.0.0.
> > We can have some feature branch in Apache off to the side to make 
> > sure
> > 2.0.0 development can happen in a shared environment before making 
> > the above switch.
> >
>
>

Re: [DISCUSS] Semantic Versioning

[Christopher <ct...@apache.org>]

On Sat, Dec 6, 2014 at 9:55 AM, <dl...@comcast.net> wrote:

> [+1 ]: adopt semver 2.0.0 (http://semver.org)
> [0 ]: adopt additional strictness to require documenting deprecation for
> at least 1 major release before possible to consider in the next major
> release
> [* ]: adopt additional strictness to ensure forward compatibility between
> bugfix releases
> [ +1]: start operating under whatever rules we adopt as of the master
> branch
> [** ]: keep the master branch named 1.7.0
> [ +1***]: define scope of these versioning compatibility rules to  be our
> current definition of "public API" and the wire version
>
> * I'm confused by this. A change in 1.6.1 is forward compatible until it's
> not. If a patch is applied to 1.6.2 that is not backwards compatible, then
> that version is not 1.6.2, it's 1.7.0.
>

This basically represents a goal to not to add new APIs without bumping the
minor release. That way, code written against 1.6.2 would run against a
1.6.1 instance.


> ** if we vote to start operating under these rules, then the version
> should calculated when development is done.
>

It can be, yes... but we can also ensure we don't have any removals that
would force the calculation to bump higher than we want it to be. Keeping
the master branch 1.7 means that we fix the calculation.


> *** where is the current definition documented?
>
>
The README


> -----Original Message-----
> From: Christopher [mailto:ctubbsii@apache.org]
> Sent: Friday, December 05, 2014 1:46 PM
> To: Accumulo Dev List
> Subject: Re: [DISCUSS] Semantic Versioning
>
> It would be helpful to this thread, if we can get some informal votes on
> the following propositions:
>
> [ ]: adopt semver 2.0.0 (http://semver.org) [ ]: adopt additional
> strictness to require documenting deprecation for at least 1 major release
> before possible to consider in the next major release [ ]: adopt additional
> strictness to ensure forward compatibility between bugfix releases [ ]:
> start operating under whatever rules we adopt as of the master branch [ ]:
> keep the master branch named 1.7.0 [ ]: define scope of these versioning
> compatibility rules to  be our current definition of "public API" and the
> wire version
>
> I'm going to assume it's a given that if any exceptional situations arise,
> we'll handle those through further discussions/voting, as appropriate.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > Christopher wrote:
> >
> >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
> >>
> >>  >  +1 to semver
> >>> >  +1 to 1 major release before removing deprecated items
> >>> >  +1 to forward compatibility between bugfix releases
> >>> >
> >>> >  What's the version # for the master branch if these rules are
> applied?
> >>> >
> >>> >
> >>>
> >> Well, I'd say1.7  still, since it is consistent with our existing
> >> rules for determining a "major" releasetoday,  *and*  it matches
> >> semver definition of a "minor" release, because it doesn't break
> >> backwards-compatibility compatibility from1.6  (with one tiny
> >> exception of dropping Instance.getConfiguration()... because it was
> >> an exceptional situation discussed in previous threads; if people are
> >> uncomfortable with that exception, I can return it to the API, if it
> >> helps achieve consensus here).
> >>
> >>
> > Sounds right to me.
> >
> > When we actually have code to land in Apache for 2.0.0, I figured we'd
> > break 1.7.X off to branch named "1.7" and master would become 2.0.0.
> > We can have some feature branch in Apache off to the side to make sure
> > 2.0.0 development can happen in a shared environment before making the
> > above switch.
> >
>
>

RE: [DISCUSS] Semantic Versioning

[dl...@comcast.net]

[+1 ]: adopt semver 2.0.0 (http://semver.org)
[0 ]: adopt additional strictness to require documenting deprecation for at least 1 major release before possible to consider in the next major release
[* ]: adopt additional strictness to ensure forward compatibility between bugfix releases
[ +1]: start operating under whatever rules we adopt as of the master branch
[** ]: keep the master branch named 1.7.0
[ +1***]: define scope of these versioning compatibility rules to  be our current definition of "public API" and the wire version

* I'm confused by this. A change in 1.6.1 is forward compatible until it's not. If a patch is applied to 1.6.2 that is not backwards compatible, then that version is not 1.6.2, it's 1.7.0.
** if we vote to start operating under these rules, then the version should calculated when development is done. 
*** where is the current definition documented?

-----Original Message-----
From: Christopher [mailto:ctubbsii@apache.org] 
Sent: Friday, December 05, 2014 1:46 PM
To: Accumulo Dev List
Subject: Re: [DISCUSS] Semantic Versioning

It would be helpful to this thread, if we can get some informal votes on the following propositions:

[ ]: adopt semver 2.0.0 (http://semver.org) [ ]: adopt additional strictness to require documenting deprecation for at least 1 major release before possible to consider in the next major release [ ]: adopt additional strictness to ensure forward compatibility between bugfix releases [ ]: start operating under whatever rules we adopt as of the master branch [ ]: keep the master branch named 1.7.0 [ ]: define scope of these versioning compatibility rules to  be our current definition of "public API" and the wire version

I'm going to assume it's a given that if any exceptional situations arise, we'll handle those through further discussions/voting, as appropriate.


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

On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com> wrote:

> Christopher wrote:
>
>> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
>>
>>  >  +1 to semver
>>> >  +1 to 1 major release before removing deprecated items
>>> >  +1 to forward compatibility between bugfix releases
>>> >
>>> >  What's the version # for the master branch if these rules are applied?
>>> >
>>> >
>>>
>> Well, I'd say1.7  still, since it is consistent with our existing 
>> rules for determining a "major" releasetoday,  *and*  it matches 
>> semver definition of a "minor" release, because it doesn't break 
>> backwards-compatibility compatibility from1.6  (with one tiny 
>> exception of dropping Instance.getConfiguration()... because it was 
>> an exceptional situation discussed in previous threads; if people are 
>> uncomfortable with that exception, I can return it to the API, if it 
>> helps achieve consensus here).
>>
>>
> Sounds right to me.
>
> When we actually have code to land in Apache for 2.0.0, I figured we'd 
> break 1.7.X off to branch named "1.7" and master would become 2.0.0. 
> We can have some feature branch in Apache off to the side to make sure 
> 2.0.0 development can happen in a shared environment before making the 
> above switch.
>

Re: [DISCUSS] Semantic Versioning

[John Vines <vi...@apache.org>]

Let me try again, for clarity

[+1]: adopt semver 2.0.0 (http://semver.org)
[*]: adopt additional strictness to require documenting deprecation for at
least 1 major release before possible to consider in the next major release
[+1]: adopt additional strictness to ensure forward compatibility between
bugfix releases
[**]: start operating under whatever rules we adopt as of the master branch
[***]: keep the master branch named 1.7.0
[+1]: define scope of these versioning compatibility rules to  be our

* = Okay adopting this for the release following the release of the new API
** = This is dependent on the keep master branch named 1.7.0 so I'm afraid
to align myself to a vote against something in flux
*** = don't care (0) but it affects my other votes

On Fri, Dec 5, 2014 at 1:53 PM, Christopher <ct...@apache.org> wrote:

> Does X mean "+1" here? And, are the ones you omitted undecided, or "-1".
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Fri, Dec 5, 2014 at 1:51 PM, John Vines <vi...@apache.org> wrote:
>
>> [X]: adopt semver 2.0.0 (http://semver.org)
>> [ ]: adopt additional strictness to require documenting deprecation for at
>> least 1 major release before possible to consider in the next major
>> release
>> [X]: adopt additional strictness to ensure forward compatibility between
>> bugfix releases
>> [ ]: start operating under whatever rules we adopt as of the master branch
>> [ ]: keep the master branch named 1.7.0
>> [X]: define scope of these versioning compatibility rules to  be our
>> current definition of "public API" and the wire version
>>
>>
>> On Fri, Dec 5, 2014 at 1:46 PM, Christopher <ct...@apache.org> wrote:
>>
>> > It would be helpful to this thread, if we can get some informal votes on
>> > the following propositions:
>> >
>> > [ ]: adopt semver 2.0.0 (http://semver.org)
>> > [ ]: adopt additional strictness to require documenting deprecation for
>> at
>> > least 1 major release before possible to consider in the next major
>> release
>> > [ ]: adopt additional strictness to ensure forward compatibility between
>> > bugfix releases
>> > [ ]: start operating under whatever rules we adopt as of the master
>> branch
>> > [ ]: keep the master branch named 1.7.0
>> > [ ]: define scope of these versioning compatibility rules to  be our
>> > current definition of "public API" and the wire version
>> >
>> > I'm going to assume it's a given that if any exceptional situations
>> arise,
>> > we'll handle those through further discussions/voting, as appropriate.
>> >
>> >
>> > --
>> > Christopher L Tubbs II
>> > http://gravatar.com/ctubbsii
>> >
>> > On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com>
>> wrote:
>> >
>> > > Christopher wrote:
>> > >
>> > >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
>> > >>
>> > >>  >  +1 to semver
>> > >>> >  +1 to 1 major release before removing deprecated items
>> > >>> >  +1 to forward compatibility between bugfix releases
>> > >>> >
>> > >>> >  What's the version # for the master branch if these rules are
>> > applied?
>> > >>> >
>> > >>> >
>> > >>>
>> > >> Well, I'd say1.7  still, since it is consistent with our existing
>> rules
>> > >> for
>> > >> determining a "major" releasetoday,  *and*  it matches semver
>> definition
>> > >> of
>> > >> a "minor" release, because it doesn't break backwards-compatibility
>> > >> compatibility from1.6  (with one tiny exception of dropping
>> > >> Instance.getConfiguration()... because it was an exceptional
>> situation
>> > >> discussed in previous threads; if people are uncomfortable with that
>> > >> exception, I can return it to the API, if it helps achieve consensus
>> > >> here).
>> > >>
>> > >>
>> > > Sounds right to me.
>> > >
>> > > When we actually have code to land in Apache for 2.0.0, I figured we'd
>> > > break 1.7.X off to branch named "1.7" and master would become 2.0.0.
>> We
>> > can
>> > > have some feature branch in Apache off to the side to make sure 2.0.0
>> > > development can happen in a shared environment before making the above
>> > > switch.
>> > >
>> >
>>
>>
>> On Fri, Dec 5, 2014 at 1:46 PM, Christopher <ct...@apache.org> wrote:
>>
>> > It would be helpful to this thread, if we can get some informal votes on
>> > the following propositions:
>> >
>> > [ ]: adopt semver 2.0.0 (http://semver.org)
>> > [ ]: adopt additional strictness to require documenting deprecation for
>> at
>> > least 1 major release before possible to consider in the next major
>> release
>> > [ ]: adopt additional strictness to ensure forward compatibility between
>> > bugfix releases
>> > [ ]: start operating under whatever rules we adopt as of the master
>> branch
>> > [ ]: keep the master branch named 1.7.0
>> > [ ]: define scope of these versioning compatibility rules to  be our
>> > current definition of "public API" and the wire version
>> >
>> > I'm going to assume it's a given that if any exceptional situations
>> arise,
>> > we'll handle those through further discussions/voting, as appropriate.
>> >
>> >
>> > --
>> > Christopher L Tubbs II
>> > http://gravatar.com/ctubbsii
>> >
>> > On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com>
>> wrote:
>> >
>> > > Christopher wrote:
>> > >
>> > >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
>> > >>
>> > >>  >  +1 to semver
>> > >>> >  +1 to 1 major release before removing deprecated items
>> > >>> >  +1 to forward compatibility between bugfix releases
>> > >>> >
>> > >>> >  What's the version # for the master branch if these rules are
>> > applied?
>> > >>> >
>> > >>> >
>> > >>>
>> > >> Well, I'd say1.7  still, since it is consistent with our existing
>> rules
>> > >> for
>> > >> determining a "major" releasetoday,  *and*  it matches semver
>> definition
>> > >> of
>> > >> a "minor" release, because it doesn't break backwards-compatibility
>> > >> compatibility from1.6  (with one tiny exception of dropping
>> > >> Instance.getConfiguration()... because it was an exceptional
>> situation
>> > >> discussed in previous threads; if people are uncomfortable with that
>> > >> exception, I can return it to the API, if it helps achieve consensus
>> > >> here).
>> > >>
>> > >>
>> > > Sounds right to me.
>> > >
>> > > When we actually have code to land in Apache for 2.0.0, I figured we'd
>> > > break 1.7.X off to branch named "1.7" and master would become 2.0.0.
>> We
>> > can
>> > > have some feature branch in Apache off to the side to make sure 2.0.0
>> > > development can happen in a shared environment before making the above
>> > > switch.
>> > >
>> >
>>
>
>

Re: [DISCUSS] Semantic Versioning

[Christopher <ct...@apache.org>]

Does X mean "+1" here? And, are the ones you omitted undecided, or "-1".


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

On Fri, Dec 5, 2014 at 1:51 PM, John Vines <vi...@apache.org> wrote:

> [X]: adopt semver 2.0.0 (http://semver.org)
> [ ]: adopt additional strictness to require documenting deprecation for at
> least 1 major release before possible to consider in the next major release
> [X]: adopt additional strictness to ensure forward compatibility between
> bugfix releases
> [ ]: start operating under whatever rules we adopt as of the master branch
> [ ]: keep the master branch named 1.7.0
> [X]: define scope of these versioning compatibility rules to  be our
> current definition of "public API" and the wire version
>
>
> On Fri, Dec 5, 2014 at 1:46 PM, Christopher <ct...@apache.org> wrote:
>
> > It would be helpful to this thread, if we can get some informal votes on
> > the following propositions:
> >
> > [ ]: adopt semver 2.0.0 (http://semver.org)
> > [ ]: adopt additional strictness to require documenting deprecation for
> at
> > least 1 major release before possible to consider in the next major
> release
> > [ ]: adopt additional strictness to ensure forward compatibility between
> > bugfix releases
> > [ ]: start operating under whatever rules we adopt as of the master
> branch
> > [ ]: keep the master branch named 1.7.0
> > [ ]: define scope of these versioning compatibility rules to  be our
> > current definition of "public API" and the wire version
> >
> > I'm going to assume it's a given that if any exceptional situations
> arise,
> > we'll handle those through further discussions/voting, as appropriate.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com> wrote:
> >
> > > Christopher wrote:
> > >
> > >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
> > >>
> > >>  >  +1 to semver
> > >>> >  +1 to 1 major release before removing deprecated items
> > >>> >  +1 to forward compatibility between bugfix releases
> > >>> >
> > >>> >  What's the version # for the master branch if these rules are
> > applied?
> > >>> >
> > >>> >
> > >>>
> > >> Well, I'd say1.7  still, since it is consistent with our existing
> rules
> > >> for
> > >> determining a "major" releasetoday,  *and*  it matches semver
> definition
> > >> of
> > >> a "minor" release, because it doesn't break backwards-compatibility
> > >> compatibility from1.6  (with one tiny exception of dropping
> > >> Instance.getConfiguration()... because it was an exceptional situation
> > >> discussed in previous threads; if people are uncomfortable with that
> > >> exception, I can return it to the API, if it helps achieve consensus
> > >> here).
> > >>
> > >>
> > > Sounds right to me.
> > >
> > > When we actually have code to land in Apache for 2.0.0, I figured we'd
> > > break 1.7.X off to branch named "1.7" and master would become 2.0.0. We
> > can
> > > have some feature branch in Apache off to the side to make sure 2.0.0
> > > development can happen in a shared environment before making the above
> > > switch.
> > >
> >
>
>
> On Fri, Dec 5, 2014 at 1:46 PM, Christopher <ct...@apache.org> wrote:
>
> > It would be helpful to this thread, if we can get some informal votes on
> > the following propositions:
> >
> > [ ]: adopt semver 2.0.0 (http://semver.org)
> > [ ]: adopt additional strictness to require documenting deprecation for
> at
> > least 1 major release before possible to consider in the next major
> release
> > [ ]: adopt additional strictness to ensure forward compatibility between
> > bugfix releases
> > [ ]: start operating under whatever rules we adopt as of the master
> branch
> > [ ]: keep the master branch named 1.7.0
> > [ ]: define scope of these versioning compatibility rules to  be our
> > current definition of "public API" and the wire version
> >
> > I'm going to assume it's a given that if any exceptional situations
> arise,
> > we'll handle those through further discussions/voting, as appropriate.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com> wrote:
> >
> > > Christopher wrote:
> > >
> > >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
> > >>
> > >>  >  +1 to semver
> > >>> >  +1 to 1 major release before removing deprecated items
> > >>> >  +1 to forward compatibility between bugfix releases
> > >>> >
> > >>> >  What's the version # for the master branch if these rules are
> > applied?
> > >>> >
> > >>> >
> > >>>
> > >> Well, I'd say1.7  still, since it is consistent with our existing
> rules
> > >> for
> > >> determining a "major" releasetoday,  *and*  it matches semver
> definition
> > >> of
> > >> a "minor" release, because it doesn't break backwards-compatibility
> > >> compatibility from1.6  (with one tiny exception of dropping
> > >> Instance.getConfiguration()... because it was an exceptional situation
> > >> discussed in previous threads; if people are uncomfortable with that
> > >> exception, I can return it to the API, if it helps achieve consensus
> > >> here).
> > >>
> > >>
> > > Sounds right to me.
> > >
> > > When we actually have code to land in Apache for 2.0.0, I figured we'd
> > > break 1.7.X off to branch named "1.7" and master would become 2.0.0. We
> > can
> > > have some feature branch in Apache off to the side to make sure 2.0.0
> > > development can happen in a shared environment before making the above
> > > switch.
> > >
> >
>

Re: [DISCUSS] Semantic Versioning

[John Vines <vi...@apache.org>]

[X]: adopt semver 2.0.0 (http://semver.org)
[ ]: adopt additional strictness to require documenting deprecation for at
least 1 major release before possible to consider in the next major release
[X]: adopt additional strictness to ensure forward compatibility between
bugfix releases
[ ]: start operating under whatever rules we adopt as of the master branch
[ ]: keep the master branch named 1.7.0
[X]: define scope of these versioning compatibility rules to  be our
current definition of "public API" and the wire version


On Fri, Dec 5, 2014 at 1:46 PM, Christopher <ct...@apache.org> wrote:

> It would be helpful to this thread, if we can get some informal votes on
> the following propositions:
>
> [ ]: adopt semver 2.0.0 (http://semver.org)
> [ ]: adopt additional strictness to require documenting deprecation for at
> least 1 major release before possible to consider in the next major release
> [ ]: adopt additional strictness to ensure forward compatibility between
> bugfix releases
> [ ]: start operating under whatever rules we adopt as of the master branch
> [ ]: keep the master branch named 1.7.0
> [ ]: define scope of these versioning compatibility rules to  be our
> current definition of "public API" and the wire version
>
> I'm going to assume it's a given that if any exceptional situations arise,
> we'll handle those through further discussions/voting, as appropriate.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > Christopher wrote:
> >
> >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
> >>
> >>  >  +1 to semver
> >>> >  +1 to 1 major release before removing deprecated items
> >>> >  +1 to forward compatibility between bugfix releases
> >>> >
> >>> >  What's the version # for the master branch if these rules are
> applied?
> >>> >
> >>> >
> >>>
> >> Well, I'd say1.7  still, since it is consistent with our existing rules
> >> for
> >> determining a "major" releasetoday,  *and*  it matches semver definition
> >> of
> >> a "minor" release, because it doesn't break backwards-compatibility
> >> compatibility from1.6  (with one tiny exception of dropping
> >> Instance.getConfiguration()... because it was an exceptional situation
> >> discussed in previous threads; if people are uncomfortable with that
> >> exception, I can return it to the API, if it helps achieve consensus
> >> here).
> >>
> >>
> > Sounds right to me.
> >
> > When we actually have code to land in Apache for 2.0.0, I figured we'd
> > break 1.7.X off to branch named "1.7" and master would become 2.0.0. We
> can
> > have some feature branch in Apache off to the side to make sure 2.0.0
> > development can happen in a shared environment before making the above
> > switch.
> >
>


On Fri, Dec 5, 2014 at 1:46 PM, Christopher <ct...@apache.org> wrote:

> It would be helpful to this thread, if we can get some informal votes on
> the following propositions:
>
> [ ]: adopt semver 2.0.0 (http://semver.org)
> [ ]: adopt additional strictness to require documenting deprecation for at
> least 1 major release before possible to consider in the next major release
> [ ]: adopt additional strictness to ensure forward compatibility between
> bugfix releases
> [ ]: start operating under whatever rules we adopt as of the master branch
> [ ]: keep the master branch named 1.7.0
> [ ]: define scope of these versioning compatibility rules to  be our
> current definition of "public API" and the wire version
>
> I'm going to assume it's a given that if any exceptional situations arise,
> we'll handle those through further discussions/voting, as appropriate.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > Christopher wrote:
> >
> >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
> >>
> >>  >  +1 to semver
> >>> >  +1 to 1 major release before removing deprecated items
> >>> >  +1 to forward compatibility between bugfix releases
> >>> >
> >>> >  What's the version # for the master branch if these rules are
> applied?
> >>> >
> >>> >
> >>>
> >> Well, I'd say1.7  still, since it is consistent with our existing rules
> >> for
> >> determining a "major" releasetoday,  *and*  it matches semver definition
> >> of
> >> a "minor" release, because it doesn't break backwards-compatibility
> >> compatibility from1.6  (with one tiny exception of dropping
> >> Instance.getConfiguration()... because it was an exceptional situation
> >> discussed in previous threads; if people are uncomfortable with that
> >> exception, I can return it to the API, if it helps achieve consensus
> >> here).
> >>
> >>
> > Sounds right to me.
> >
> > When we actually have code to land in Apache for 2.0.0, I figured we'd
> > break 1.7.X off to branch named "1.7" and master would become 2.0.0. We
> can
> > have some feature branch in Apache off to the side to make sure 2.0.0
> > development can happen in a shared environment before making the above
> > switch.
> >
>

Re: [DISCUSS] Semantic Versioning

[Josh Elser <jo...@gmail.com>]

[+1]: adopt semver 2.0.0 (http://semver.org)
[+1]: adopt additional strictness to require documenting deprecation for at
least 1 major release before possible to consider in the next major release
[+1]: adopt additional strictness to ensure forward compatibility between
bugfix releases
[-0]: start operating under whatever rules we adopt as of the master branch
[-0]: keep the master branch named 1.7.0
[-0]: define scope of these versioning compatibility rules to  be our
current definition of "public API" and the wire version

As I said down below, I don't think trying to fully adopt semver when 
we're still on 1.X is going to work out well because we're missing the 3 
necessary version components. I think we should continue to operate as 
we had and just address whatever concerns devs have until 2.0.0.

Also, as Keith very well stated already, wire compat is a new guarantee 
and, if we do decide to make such a guarantee, we should have some 
mechanism in place for the first such release we make with the 
guarantee. A quick solution here is to have a champion behind the 
wire-compat testing who can shepherd it into the targeted release.

Christopher wrote:
> It would be helpful to this thread, if we can get some informal votes on
> the following propositions:
>
> [ ]: adopt semver 2.0.0 (http://semver.org)
> [ ]: adopt additional strictness to require documenting deprecation for at
> least 1 major release before possible to consider in the next major release
> [ ]: adopt additional strictness to ensure forward compatibility between
> bugfix releases
> [ ]: start operating under whatever rules we adopt as of the master branch
> [ ]: keep the master branch named 1.7.0
> [ ]: define scope of these versioning compatibility rules to  be our
> current definition of "public API" and the wire version
>
> I'm going to assume it's a given that if any exceptional situations arise,
> we'll handle those through further discussions/voting, as appropriate.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser<jo...@gmail.com>  wrote:
>
>> Christopher wrote:
>>
>>> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>   wrote:
>>>
>>>   >   +1 to semver
>>>>>   +1 to 1 major release before removing deprecated items
>>>>>   +1 to forward compatibility between bugfix releases
>>>>>
>>>>>   What's the version # for the master branch if these rules are applied?
>>>>>
>>>>>
>>> Well, I'd say1.7  still, since it is consistent with our existing rules
>>> for
>>> determining a "major" releasetoday,  *and*  it matches semver definition
>>> of
>>> a "minor" release, because it doesn't break backwards-compatibility
>>> compatibility from1.6  (with one tiny exception of dropping
>>> Instance.getConfiguration()... because it was an exceptional situation
>>> discussed in previous threads; if people are uncomfortable with that
>>> exception, I can return it to the API, if it helps achieve consensus
>>> here).
>>>
>>>
>> Sounds right to me.
>>
>> When we actually have code to land in Apache for 2.0.0, I figured we'd
>> break 1.7.X off to branch named "1.7" and master would become 2.0.0. We can
>> have some feature branch in Apache off to the side to make sure 2.0.0
>> development can happen in a shared environment before making the above
>> switch.
>>
>

Re: [DISCUSS] Semantic Versioning

[David Medinets <da...@gmail.com>]

[ +1 ]: adopt semver 2.0.0 (http://semver.org)
[ +1 ]: adopt additional strictness to require documenting deprecation for at
least 1 major release before possible to consider in the next major release
[ +1 ]: adopt additional strictness to ensure forward compatibility between
bugfix releases
[ 0 ]: start operating under whatever rules we adopt as of the master branch
[ +1 ]: keep the master branch named 1.7.0
[ 0 ]: define scope of these versioning compatibility rules to  be our
current definition of "public API" and the wire version

Re: [DISCUSS] Semantic Versioning

[Christopher <ct...@apache.org>]

I'm inclined to agree with you on the wire version. I guess it's something
I proposed without thinking it through. If the API is backwards compatible,
then the user just needs to use the newer jars to be able to function
without changing their application code.

I think we would need forward compatibility within bugfix versions, though,
for the wire version, in order to support rolling upgrades, which is what
we're doing now with the wire version. If we want to support rolling
upgrades beyond that, I guess we'll have to discuss wire version
compatibility separately in that context.


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

On Fri, Dec 5, 2014 at 2:11 PM, Keith Turner <ke...@deenlo.com> wrote:

> On Fri, Dec 5, 2014 at 1:46 PM, Christopher <ct...@apache.org> wrote:
>
> > It would be helpful to this thread, if we can get some informal votes on
> > the following propositions:
> >
> > [ ]: adopt semver 2.0.0 (http://semver.org)
> > [ ]: adopt additional strictness to require documenting deprecation for
> at
> > least 1 major release before possible to consider in the next major
> release
> > [ ]: adopt additional strictness to ensure forward compatibility between
> > bugfix releases
> > [ ]: start operating under whatever rules we adopt as of the master
> branch
> > [ ]: keep the master branch named 1.7.0
> > [ ]: define scope of these versioning compatibility rules to  be our
> > current definition of "public API" and the wire version
> >
> >
>
> [+1]: adopt semver 2.0.0 (http://semver.org)
>
> I have concerns that the following may be too strict.
>
> [+0]: adopt additional strictness to require documenting deprecation for at
> least 1 major release before possible to consider in the next major release
> [+1]: adopt additional strictness to ensure forward compatibility between
> bugfix releases
> [+1]: start operating under whatever rules we adopt as of the master branch
> [+1]: keep the master branch named 1.7.0
> [-1]: define scope of these versioning compatibility rules to  be our
> current definition of "public API" and the wire version
>
> We have not offered guarantees of wire compatibility across minor releases
> before.   This would be something new.  I am not opposed to it on
> principal, but I think doing it properly would require a test suite that
> verifies the complete 1.(X-1) client API/jar works against a 1.X server.
> We have nothing like this, and I don't like the idea of saying we offer
> something w/ no way to validate.  In the interest of making forward
> progress, I suggest the following.
> [+1]: define scope of these versioning compatibility rules to  be our
> current definition of "public API"
>
>
>
>
> > I'm going to assume it's a given that if any exceptional situations
> arise,
> > we'll handle those through further discussions/voting, as appropriate.
> >
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
> > On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com> wrote:
> >
> > > Christopher wrote:
> > >
> > >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
> > >>
> > >>  >  +1 to semver
> > >>> >  +1 to 1 major release before removing deprecated items
> > >>> >  +1 to forward compatibility between bugfix releases
> > >>> >
> > >>> >  What's the version # for the master branch if these rules are
> > applied?
> > >>> >
> > >>> >
> > >>>
> > >> Well, I'd say1.7  still, since it is consistent with our existing
> rules
> > >> for
> > >> determining a "major" releasetoday,  *and*  it matches semver
> definition
> > >> of
> > >> a "minor" release, because it doesn't break backwards-compatibility
> > >> compatibility from1.6  (with one tiny exception of dropping
> > >> Instance.getConfiguration()... because it was an exceptional situation
> > >> discussed in previous threads; if people are uncomfortable with that
> > >> exception, I can return it to the API, if it helps achieve consensus
> > >> here).
> > >>
> > >>
> > > Sounds right to me.
> > >
> > > When we actually have code to land in Apache for 2.0.0, I figured we'd
> > > break 1.7.X off to branch named "1.7" and master would become 2.0.0. We
> > can
> > > have some feature branch in Apache off to the side to make sure 2.0.0
> > > development can happen in a shared environment before making the above
> > > switch.
> > >
> >
>

Re: [DISCUSS] Semantic Versioning

[Keith Turner <ke...@deenlo.com>]

On Fri, Dec 5, 2014 at 1:46 PM, Christopher <ct...@apache.org> wrote:

> It would be helpful to this thread, if we can get some informal votes on
> the following propositions:
>
> [ ]: adopt semver 2.0.0 (http://semver.org)
> [ ]: adopt additional strictness to require documenting deprecation for at
> least 1 major release before possible to consider in the next major release
> [ ]: adopt additional strictness to ensure forward compatibility between
> bugfix releases
> [ ]: start operating under whatever rules we adopt as of the master branch
> [ ]: keep the master branch named 1.7.0
> [ ]: define scope of these versioning compatibility rules to  be our
> current definition of "public API" and the wire version
>
>

[+1]: adopt semver 2.0.0 (http://semver.org)

I have concerns that the following may be too strict.

[+0]: adopt additional strictness to require documenting deprecation for at
least 1 major release before possible to consider in the next major release
[+1]: adopt additional strictness to ensure forward compatibility between
bugfix releases
[+1]: start operating under whatever rules we adopt as of the master branch
[+1]: keep the master branch named 1.7.0
[-1]: define scope of these versioning compatibility rules to  be our
current definition of "public API" and the wire version

We have not offered guarantees of wire compatibility across minor releases
before.   This would be something new.  I am not opposed to it on
principal, but I think doing it properly would require a test suite that
verifies the complete 1.(X-1) client API/jar works against a 1.X server.
We have nothing like this, and I don't like the idea of saying we offer
something w/ no way to validate.  In the interest of making forward
progress, I suggest the following.
[+1]: define scope of these versioning compatibility rules to  be our
current definition of "public API"




> I'm going to assume it's a given that if any exceptional situations arise,
> we'll handle those through further discussions/voting, as appropriate.
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com> wrote:
>
> > Christopher wrote:
> >
> >> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
> >>
> >>  >  +1 to semver
> >>> >  +1 to 1 major release before removing deprecated items
> >>> >  +1 to forward compatibility between bugfix releases
> >>> >
> >>> >  What's the version # for the master branch if these rules are
> applied?
> >>> >
> >>> >
> >>>
> >> Well, I'd say1.7  still, since it is consistent with our existing rules
> >> for
> >> determining a "major" releasetoday,  *and*  it matches semver definition
> >> of
> >> a "minor" release, because it doesn't break backwards-compatibility
> >> compatibility from1.6  (with one tiny exception of dropping
> >> Instance.getConfiguration()... because it was an exceptional situation
> >> discussed in previous threads; if people are uncomfortable with that
> >> exception, I can return it to the API, if it helps achieve consensus
> >> here).
> >>
> >>
> > Sounds right to me.
> >
> > When we actually have code to land in Apache for 2.0.0, I figured we'd
> > break 1.7.X off to branch named "1.7" and master would become 2.0.0. We
> can
> > have some feature branch in Apache off to the side to make sure 2.0.0
> > development can happen in a shared environment before making the above
> > switch.
> >
>

Re: [DISCUSS] Semantic Versioning

[Christopher <ct...@apache.org>]

It would be helpful to this thread, if we can get some informal votes on
the following propositions:

[ ]: adopt semver 2.0.0 (http://semver.org)
[ ]: adopt additional strictness to require documenting deprecation for at
least 1 major release before possible to consider in the next major release
[ ]: adopt additional strictness to ensure forward compatibility between
bugfix releases
[ ]: start operating under whatever rules we adopt as of the master branch
[ ]: keep the master branch named 1.7.0
[ ]: define scope of these versioning compatibility rules to  be our
current definition of "public API" and the wire version

I'm going to assume it's a given that if any exceptional situations arise,
we'll handle those through further discussions/voting, as appropriate.


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

On Thu, Dec 4, 2014 at 2:09 PM, Josh Elser <jo...@gmail.com> wrote:

> Christopher wrote:
>
>> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
>>
>>  >  +1 to semver
>>> >  +1 to 1 major release before removing deprecated items
>>> >  +1 to forward compatibility between bugfix releases
>>> >
>>> >  What's the version # for the master branch if these rules are applied?
>>> >
>>> >
>>>
>> Well, I'd say1.7  still, since it is consistent with our existing rules
>> for
>> determining a "major" releasetoday,  *and*  it matches semver definition
>> of
>> a "minor" release, because it doesn't break backwards-compatibility
>> compatibility from1.6  (with one tiny exception of dropping
>> Instance.getConfiguration()... because it was an exceptional situation
>> discussed in previous threads; if people are uncomfortable with that
>> exception, I can return it to the API, if it helps achieve consensus
>> here).
>>
>>
> Sounds right to me.
>
> When we actually have code to land in Apache for 2.0.0, I figured we'd
> break 1.7.X off to branch named "1.7" and master would become 2.0.0. We can
> have some feature branch in Apache off to the side to make sure 2.0.0
> development can happen in a shared environment before making the above
> switch.
>

Re: [DISCUSS] Semantic Versioning

[Josh Elser <jo...@gmail.com>]

Christopher wrote:
> On Wed, Dec 3, 2014 at 1:41 PM,<dl...@comcast.net>  wrote:
>
>> >  +1 to semver
>> >  +1 to 1 major release before removing deprecated items
>> >  +1 to forward compatibility between bugfix releases
>> >
>> >  What's the version # for the master branch if these rules are applied?
>> >
>> >
> Well, I'd say1.7  still, since it is consistent with our existing rules for
> determining a "major" releasetoday,  *and*  it matches semver definition of
> a "minor" release, because it doesn't break backwards-compatibility
> compatibility from1.6  (with one tiny exception of dropping
> Instance.getConfiguration()... because it was an exceptional situation
> discussed in previous threads; if people are uncomfortable with that
> exception, I can return it to the API, if it helps achieve consensus here).
>

Sounds right to me.

When we actually have code to land in Apache for 2.0.0, I figured we'd 
break 1.7.X off to branch named "1.7" and master would become 2.0.0. We 
can have some feature branch in Apache off to the side to make sure 
2.0.0 development can happen in a shared environment before making the 
above switch.

Re: [DISCUSS] Semantic Versioning

[Christopher <ct...@apache.org>]

On Wed, Dec 3, 2014 at 1:41 PM, <dl...@comcast.net> wrote:

> +1 to semver
> +1 to 1 major release before removing deprecated items
> +1 to forward compatibility between bugfix releases
>
> What's the version # for the master branch if these rules are applied?
>
>
Well, I'd say 1.7 still, since it is consistent with our existing rules for
determining a "major" release today, *and* it matches semver definition of
a "minor" release, because it doesn't break backwards-compatibility
compatibility from 1.6 (with one tiny exception of dropping
Instance.getConfiguration()... because it was an exceptional situation
discussed in previous threads; if people are uncomfortable with that
exception, I can return it to the API, if it helps achieve consensus here).


> ----- Original Message -----
>
> From: "Christopher" <ct...@apache.org>
> To: "Accumulo Dev List" <de...@accumulo.apache.org>
> Sent: Wednesday, December 3, 2014 1:30:20 PM
> Subject: [DISCUSS] Semantic Versioning
>
> I don't want to issue another vote right now, but I just (re-read) the
> semantic versioning 2.0.0 document (http://semver.org/), and I think we
> should just go ahead and adopt it and start abiding by it.
>
> In addition, I'd also like to ensure we provide some long-term stability
> for deprecations. Semver only says we should have at least 1 minor release
> with the deprecation documented. I think we should have at least one
> (typically: exactly one) major release with the deprecation documented,
> before breaking it in the next major release after that.
>
> Also, Semver also does not say anything about forward-compatibility, but I
> think we do probably want to ensure forward compatibility between "patch"
> releases (aka "bugfix" releases), in addition to backwards-compatibility. I
> don't think it would make sense to add forward-compatibility to "minor"
> releases, though, because that would prevent adding non-breaking features,
> and that's the explicit purpose of Semver's "minor" releases.
>
> We've previously discussed versioning semantics, but never came to a
> decision. I recall that there was some views that we should defer applying
> these semantics until after 2.0 (that position was used to justify several
> backports). However, given the stronger concerns more recently, regarding
> API stability, it appears as though those views are different now, and
> maybe we should just start applying this from 1.7 and forward.
>
> Semver with these two additions (forward-compatibility for patch releases,
> and longer-deprecation cycle), basically encompasses the guidelines that I
> suggested in the last [VOTE] thread about what to do between 1.7.0 and
> 2.0.0, and also clarifies what I was thinking in terms of deprecations in
> 2.0. If we adopt this, that thread is essentially moot.
>
> Thoughts? Are there any additions we'd like to see? Strong statements that
> go beyond semver? Should we just vote on this?
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>

Re: [DISCUSS] Semantic Versioning

[dl...@comcast.net]

+1 to semver 
+1 to 1 major release before removing deprecated items 
+1 to forward compatibility between bugfix releases 

What's the version # for the master branch if these rules are applied? 

----- Original Message -----

From: "Christopher" <ct...@apache.org> 
To: "Accumulo Dev List" <de...@accumulo.apache.org> 
Sent: Wednesday, December 3, 2014 1:30:20 PM 
Subject: [DISCUSS] Semantic Versioning 

I don't want to issue another vote right now, but I just (re-read) the 
semantic versioning 2.0.0 document (http://semver.org/), and I think we 
should just go ahead and adopt it and start abiding by it. 

In addition, I'd also like to ensure we provide some long-term stability 
for deprecations. Semver only says we should have at least 1 minor release 
with the deprecation documented. I think we should have at least one 
(typically: exactly one) major release with the deprecation documented, 
before breaking it in the next major release after that. 

Also, Semver also does not say anything about forward-compatibility, but I 
think we do probably want to ensure forward compatibility between "patch" 
releases (aka "bugfix" releases), in addition to backwards-compatibility. I 
don't think it would make sense to add forward-compatibility to "minor" 
releases, though, because that would prevent adding non-breaking features, 
and that's the explicit purpose of Semver's "minor" releases. 

We've previously discussed versioning semantics, but never came to a 
decision. I recall that there was some views that we should defer applying 
these semantics until after 2.0 (that position was used to justify several 
backports). However, given the stronger concerns more recently, regarding 
API stability, it appears as though those views are different now, and 
maybe we should just start applying this from 1.7 and forward. 

Semver with these two additions (forward-compatibility for patch releases, 
and longer-deprecation cycle), basically encompasses the guidelines that I 
suggested in the last [VOTE] thread about what to do between 1.7.0 and 
2.0.0, and also clarifies what I was thinking in terms of deprecations in 
2.0. If we adopt this, that thread is essentially moot. 

Thoughts? Are there any additions we'd like to see? Strong statements that 
go beyond semver? Should we just vote on this? 

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

Re: [DISCUSS] Semantic Versioning

[Christopher <ct...@apache.org>]

On Thu, Dec 4, 2014 at 7:53 AM, Sean Busbey <bu...@cloudera.com> wrote:

> One if the prerequisites that delayed us on adopting semver is that we
> haven't defined what is covered when considering statement about
> compatibility.
>
>
True. We can use our current definition of "public API", and our "wire
version" and "data version" (now that we have one).
Granted, the definition of our "public API" would be larger for a short
transition period (adds the client jar in 2.0), until deprecated code goes
away. Despite the slight complexity of the current definition of "public
API", I think the benefits of actually having a reliable statement of
intent regarding compatibility guarantees significantly outweighs any
negative consequences of having that complicated definition. And, in any
case, that definition is complicated today, and we've been doing something
like semver with that complicated definition already.


> We'll need to come up with at least a first pass before we could vote. I'd
> prefer it not just be the way we currently define the public API, since
> that doesn't cover many practical concerns.
>
> IIRC, one of the main reasons for waiting to 2.0 was to make explaining the
> transition easier by allowing our versions to be roughly categorized as 1.x
> and 2.x releases. Is anyone still concerned about this?
>
>
Honestly, I probably was concerned about this in the past. But, right now,
I think it's more important that we establish strong versioning semantics
so we can offer API compatibility guarantees to users who already use our
current API and pretty much understand what we mean when we say "public
API".


> --
> Sean
> On Dec 3, 2014 12:30 PM, "Christopher" <ct...@apache.org> wrote:
>
> > I don't want to issue another vote right now, but I just (re-read) the
> > semantic versioning 2.0.0 document (http://semver.org/), and I think we
> > should just go ahead and adopt it and start abiding by it.
> >
> > In addition, I'd also like to ensure we provide some long-term stability
> > for deprecations. Semver only says we should have at least 1 minor
> release
> > with the deprecation documented. I think we should have at least one
> > (typically: exactly one) major release with the deprecation documented,
> > before breaking it in the next major release after that.
> >
> > Also, Semver also does not say anything about forward-compatibility, but
> I
> > think we do probably want to ensure forward compatibility between "patch"
> > releases (aka "bugfix" releases), in addition to
> backwards-compatibility. I
> > don't think it would make sense to add forward-compatibility to "minor"
> > releases, though, because that would prevent adding non-breaking
> features,
> > and that's the explicit purpose of Semver's "minor" releases.
> >
> > We've previously discussed versioning semantics, but never came to a
> > decision. I recall that there was some views that we should defer
> applying
> > these semantics until after 2.0 (that position was used to justify
> several
> > backports). However, given the stronger concerns more recently, regarding
> > API stability, it appears as though those views are different now, and
> > maybe we should just start applying this from 1.7 and forward.
> >
> > Semver with these two additions (forward-compatibility for patch
> releases,
> > and longer-deprecation cycle), basically encompasses the guidelines that
> I
> > suggested in the last [VOTE] thread about what to do between 1.7.0 and
> > 2.0.0, and also clarifies what I was thinking in terms of deprecations in
> > 2.0. If we adopt this, that thread is essentially moot.
> >
> > Thoughts? Are there any additions we'd like to see? Strong statements
> that
> > go beyond semver? Should we just vote on this?
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
> >
>

Re: [DISCUSS] Semantic Versioning

[Sean Busbey <bu...@cloudera.com>]

One if the prerequisites that delayed us on adopting semver is that we
haven't defined what is covered when considering statement about
compatibility.

We'll need to come up with at least a first pass before we could vote. I'd
prefer it not just be the way we currently define the public API, since
that doesn't cover many practical concerns.

IIRC, one of the main reasons for waiting to 2.0 was to make explaining the
transition easier by allowing our versions to be roughly categorized as 1.x
and 2.x releases. Is anyone still concerned about this?

-- 
Sean
On Dec 3, 2014 12:30 PM, "Christopher" <ct...@apache.org> wrote:

> I don't want to issue another vote right now, but I just (re-read) the
> semantic versioning 2.0.0 document (http://semver.org/), and I think we
> should just go ahead and adopt it and start abiding by it.
>
> In addition, I'd also like to ensure we provide some long-term stability
> for deprecations. Semver only says we should have at least 1 minor release
> with the deprecation documented. I think we should have at least one
> (typically: exactly one) major release with the deprecation documented,
> before breaking it in the next major release after that.
>
> Also, Semver also does not say anything about forward-compatibility, but I
> think we do probably want to ensure forward compatibility between "patch"
> releases (aka "bugfix" releases), in addition to backwards-compatibility. I
> don't think it would make sense to add forward-compatibility to "minor"
> releases, though, because that would prevent adding non-breaking features,
> and that's the explicit purpose of Semver's "minor" releases.
>
> We've previously discussed versioning semantics, but never came to a
> decision. I recall that there was some views that we should defer applying
> these semantics until after 2.0 (that position was used to justify several
> backports). However, given the stronger concerns more recently, regarding
> API stability, it appears as though those views are different now, and
> maybe we should just start applying this from 1.7 and forward.
>
> Semver with these two additions (forward-compatibility for patch releases,
> and longer-deprecation cycle), basically encompasses the guidelines that I
> suggested in the last [VOTE] thread about what to do between 1.7.0 and
> 2.0.0, and also clarifies what I was thinking in terms of deprecations in
> 2.0. If we adopt this, that thread is essentially moot.
>
> Thoughts? Are there any additions we'd like to see? Strong statements that
> go beyond semver? Should we just vote on this?
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>

Fwd: [DISCUSS] Semantic Versioning

[David Marion <dm...@gmail.com>]

+1 to semver
+1 to 1 major release before removing deprecated items
+1 to forward compatibility between bugfix releases

 What's the version # for the master branch if these rules are applied?


------------------------------
*From: *"Christopher" <ct...@apache.org>
*To: *"Accumulo Dev List" <de...@accumulo.apache.org>
*Sent: *Wednesday, December 3, 2014 1:30:20 PM
*Subject: *[DISCUSS] Semantic Versioning

I don't want to issue another vote right now, but I just (re-read) the
semantic versioning 2.0.0 document (http://semver.org/), and I think we
should just go ahead and adopt it and start abiding by it.

In addition, I'd also like to ensure we provide some long-term stability
for deprecations. Semver only says we should have at least 1 minor release
with the deprecation documented. I think we should have at least one
(typically: exactly one) major release with the deprecation documented,
before breaking it in the next major release after that.

Also, Semver also does not say anything about forward-compatibility, but I
think we do probably want to ensure forward compatibility between "patch"
releases (aka "bugfix" releases), in addition to backwards-compatibility. I
don't think it would make sense to add forward-compatibility to "minor"
releases, though, because that would prevent adding non-breaking features,
and that's the explicit purpose of Semver's "minor" releases.

We've previously discussed versioning semantics, but never came to a
decision. I recall that there was some views that we should defer applying
these semantics until after 2.0 (that position was used to justify several
backports). However, given the stronger concerns more recently, regarding
API stability, it appears as though those views are different now, and
maybe we should just start applying this from 1.7 and forward.

Semver with these two additions (forward-compatibility for patch releases,
and longer-deprecation cycle), basically encompasses the guidelines that I
suggested in the last [VOTE] thread about what to do between 1.7.0 and
2.0.0, and also clarifies what I was thinking in terms of deprecations in
2.0. If we adopt this, that thread is essentially moot.

Thoughts? Are there any additions we'd like to see? Strong statements that
go beyond semver? Should we just vote on this?

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