accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: Official Guidance to users regarding removal of functions
Date Thu, 11 Dec 2014 17:19:45 GMT
On Thu, Dec 11, 2014 at 12:11 PM, 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.
>


That is perfectly fine advice in my view. In stable, long-life products,
major versions are maintained for a _long_ time. Applications rarely move
to new major versions. (I'm using Apache Lucene as a point of comparison.)
So, once an application goes into production on x.y.0, its maintainers
expect that there will be bug fixes and compatible improvements for for
_years_. Moving to a new major version is a big deal, and no one is going
to do it routinely or lightly. Many applications will reach the end of
their own EOL first. There are people still using Apache Lucene 3.x, and
the community is still prepared to make security fixes. The community will
be making functional improvements to 4.x for a very long time, even as
they/we are on the verge of shipping 5.0.


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