accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: Official Guidance to users regarding removal of functions
Date Thu, 11 Dec 2014 16:51:15 GMT

It is my understanding that our practice is to flag to-be-removed API
components with Deprecation annotations and a note for the replacement.
That notice should be around for a full major version[1], though obviously
that's of limited utility if the lifespan of the major release is short.

Right now, part of our release process is checking that the API changes
aren't "painful" (ref step 6 for major releases on [1]). What that means
isn't formally called out, but I'd expect a minimum would be that the above
warning happened.

Would expanding that guidance to include calling out removals (and their
replacements) in the release notes help your concerns?

What if we had a step where such changes were posted to user@accumulo in
advance of the release? That would give impacted users a chance to give
feedback without having to watch dev@ or commits@.

FYI, in the future you'll get better traction on these kinds of threads if
you start the subject line with "[DISCUSS]".


On Thu, Dec 11, 2014 at 10:36 AM, Kepner, Jeremy - 0553 - MITLL <> 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.


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