accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Semantic Versioning
Date Sat, 06 Dec 2014 21:20:45 GMT
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 <vines@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, <dlmarion@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, <dlmarion@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 <josh.elser@gmail.com>
> wrote:
> > >
> > > > Christopher wrote:
> > > >
> > > >> On Wed, Dec 3, 2014 at 1:41 PM,<dlmarion@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.
> > > >
> > >
> > >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message