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 21:34:12 GMT
In addition to the responses already provided, I think it'd be better to
just continue supporting 1.x with new features/bugfixes as long as there is
demand for it, would be preferred than trying to keep a 1.x shim API on top
of newer releases.


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

On Thu, Dec 11, 2014 at 2:22 PM, Adam Fuchs <afuchs@apache.org> wrote:

> Has anybody looked into separating the public API a bit more from the
> core? It seems to me that a large number of the deprecation removal
> issues are related to people failing to read section 9 of the README.
> It would be great if we built an API jar that people could build
> against, but didn't leak internal classes. Maybe this is something we
> can shoot for in the 2.0 release?
>
> Taking that a step further, it would be great if we released a 1.x API
> compatible client jar for every 2.x or later release. Does anybody
> have a feel for the maintenance costs of such a thing? Certainly
> changes to configuration options and metadata table structures will
> prove challenging. Given that we don't have a history of removing
> functionality, this ought to at least be feasible.
>
> Thoughts?
>
> Adam
>
>
> On Thu, Dec 11, 2014 at 1:54 PM, Jeremy Kepner <kepner@ll.mit.edu> wrote:
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message