For context and as a good example of how we could be less abrasive, I'm
unexpectedly spending today updating Hive with a bunch of new reflection
because methods in 1.5 on AccumuloInputFormat no longer exist in 1.7.
setZooKeeperInstance used to take two Strings, but in 1.7 this version
of the method was removed and forces client to use ClientConfiguration.
This is a good example of where we didn't have to do this and there was
next to no maintenance support on us to preserve this method.
Honestly, after writing this, I'm tempted to reinstate the old version
because doing this amount of reflection is painful and silly for clients
(and I even know what I'm doing most days!)
Mike Drob wrote:
FWIW, Java 9 is dropping methods for the first time that the JDK API is
dropping methods. Almost 20 years. Just something to consider, when we
approach the conversation of how long to keep APIs around.
On Thu, Dec 11, 2014 at 3:46 PM, Christopher<ctubb...@apache.org> wrote:
You seem to be dismissing "clean up" as an invalid. I disagree. There are
costs to keeping around deprecated APIs. That's not to say we shouldn't
keep them around for a long time... we can and perhaps should. But "clean
up" is just shorthand for all the maintainability, readability, and
usability costs. As such, I feel it incapsulates many reasons which are
sometimes difficult to express, but still valid.
With semver in place, it seems like your position could be reduced to
"support major versions longer", which is a perfectly fine goal. As long as
we have that, there's really no need to upgrade to the "latest", unless
there's a feature that you want which is difficult to backport in a minor
release. In that case, I think it's perfectly reasonable to consider the
risks of upgrading and to make the choice to upgrade and have the feature
or not upgrade and avoid API changes which affect you (if any).
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Thu, Dec 11, 2014 at 3:19 PM, Kepner, Jeremy - 0553 - MITLL<
kep...@ll.mit.edu> wrote:
So I think the bigger issue is to revisit the imperative to delete
deprecated functions (both public& private). How many instances have we
had where deleting a deprecated API (public& private) did anything more
than "clean up" the code?
On Dec 11, 2014, at 2:39 PM, John Vines<vi...@apache.org> wrote:
More likely we'd have a fully backwards compatible API for each major
version. SemVer allows for it and I think that grants us enough room
for
growth while still securing things for future releases.
On Thu, Dec 11, 2014 at 2:36 PM, Adam Fuchs<afu...@apache.org> wrote:
Awesome -- ACCUMULO-2589 gets us at least halfway there. Given this,
what would be the challenges in having and maintaining one API project
for each major version ever released?
Adam
On Thu, Dec 11, 2014 at 2:24 PM, Josh Elser<josh.el...@gmail.com>
wrote:
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<kep...@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<
bil...@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<mad...@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<
bil...@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"<vi...@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<
kep...@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.
