Adam Fuchs 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?
Yup, this is already in the works by Christopher as a part of ACCUMULO-2589.
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<[email protected]> 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<[email protected]> 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<[email protected]> 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<[email protected]>
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"<[email protected]> wrote:
Wouldn't this be resolved with our SemVer sqwitch?
On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - MITLL<
[email protected]> 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.
