accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Kepner <kep...@ll.mit.edu>
Subject Re: Official Guidance to users regarding removal of functions
Date Thu, 11 Dec 2014 18:54:04 GMT
So the simple solution is to deprecate often, but remove almost never.
It is very rare that leaving a deprecated API in place actually has a negative impact.
The code gets a little less clean, but that's fine as long as things are clearly labeled as
deprecated.
In fact, seeing the way something used to be done can often be an inspiration for something
new.
If the past is deleted, then that knowledge is lost.

I am not saying deleting can never happen, I am just saying that when it does, it is because
there absolutely no choice.  Deletion to "clean up the code" shouldn't be a valid reason for
deletion.

On Thu, Dec 11, 2014 at 12:58:13PM -0500, Christopher wrote:
> 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
View raw message