accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: Official Guidance to users regarding removal of functions
Date Thu, 11 Dec 2014 17:58:13 GMT
I don't know that it'd be "cold comfort". We can continue to support 1.x
for some time, if we choose.


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

On Thu, Dec 11, 2014 at 12:53 PM, Billie Rinaldi <billie@apache.org> wrote:

> Actually, I wasn't suggesting anything.  I was providing elaboration on
> what John was referring to.  I imagine that stronger API guarantees will be
> cold comfort in the face of a 1.0 -> 2.0 upgrade.  However, if we had been
> using semver all along, there would have been much less pain for users in
> the 1.x series.  Also, adopting semver would mean that going from 1.6 to a
> hypothetical 1.7 would not suffer from the same upgrade issues.  I doubt
> that we could retroactively mitigate the differences in minor versions,
> though, so going from 1.3/1.4/1.5 to 1.7 would still be hard.
>
> On Thu, Dec 11, 2014 at 9:11 AM, Mike Drob <madrob@cloudera.com> wrote:
>
> > Billie,
> >
> > Not to be glib, but it reads like your suggestion to Jeremy for when we
> > have a 2.0.0 release (assuming semver passes) is to take option (2) Don't
> > upgrade Accumulo.
> >
> > Please correct my misunderstanding.
> >
> > Mike
> >
> > On Thu, Dec 11, 2014 at 11:07 AM, Billie Rinaldi <billie@apache.org>
> > wrote:
> >
> > > To clarify John's question: if our vote to adopt semver 2.0.0 passes,
> our
> > > intention will be to no longer have breaking public API changes unless
> > the
> > > major version number is incremented, i.e. 1.x.x -> 2.x.x. An important
> > > aspect of semantic versioning is defining what is considered part of
> the
> > > public API. So if there are things you need to remain consistent that
> are
> > > not covered by Section 9 of the README, we should discuss adding them.
> > > Actually, strengthening what we consider to be the public API is likely
> > to
> > > be a separate conversation in which (I hope) we will engage the user
> > list.
> > > On Dec 11, 2014 11:51 AM, "John Vines" <vines@apache.org> wrote:
> > >
> > > > Wouldn't this be resolved with our SemVer sqwitch?
> > > >
> > > > On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - MITLL <
> > > > kepner@ll.mit.edu> wrote:
> > > >
> > > > > When we remove functions, do we have any official guidance to our
> > users
> > > > > who may have built applications that use those functions?
> > > > >
> > > > > Right now, the official position is that the Accumulo developers
> can
> > > > > remove based on a consensus vote. However, this provides no
> guidance
> > to
> > > > > users as to what they are suppose to do? As it stands, our guidance
> > is
> > > > that
> > > > > they have the following choices:
> > > > >
> > > > > (0) Diligently watch the Accumulo e-mail list and aggressively
> weigh
> > in
> > > > on
> > > > > any vote to remove functions that may impact them.
> > > > >
> > > > > (1) Find someone to modify the original source code of their
> > > > applications,
> > > > > build it, and *re-verify* the application. I emphasise the
> re-verify
> > > > > because that is usually the most costly part of the process that
> > often
> > > > > won't get approved by management.
> > > > >
> > > > > (2) Don't upgrade Accumulo.
> > > > >
> > > >
> > >
> >
>

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