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, <[email protected]> wrote: > " This basically represents a goal to not to add new APIs without bumping > the minor release." > > I didn't think that with semver you could change the API in a patch > release. An API change, if backwards compatible, requires a new MINOR > release. Am I reading 6, 7, 8 and in the specification incorrectly? I might > need an example. > > -----Original Message----- > From: Christopher [mailto:[email protected]] > 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, <[email protected]> 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:[email protected]] > > 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 <[email protected]> wrote: > > > > > Christopher wrote: > > > > > >> On Wed, Dec 3, 2014 at 1:41 PM,<[email protected]> 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. > > > > > > > > >
