(I was still confused so I just chatted with John on the subject of his -1)
He was under the impression that it would not be feasible to leave the
existing 1.X APIs in place with the creation of the 2.0 APIs; whereas, I
had assumed that this wouldn't be an issue.
He brought up the issue of how we plan to handle exceptions in the new
API which, would very likely, include changes to the Thrift APIs as
well. If this is the case, we'd now have to support the 1.X API (while
it existed as deprecated) as well as the new 2.0 API. This would likely
affect how we actually want 2.0 API to operate.
This all kind of boils down to confusion over whether or not there is
any compatibility between 1.x and 2.0. If 2.0 is a clean break from 1.x,
this thread is pointless. Otherwise, we risk not getting the APIs we
really want.
Does this help clarify the concern?
John Vines wrote:
I believe I've explained it in detail. For 2.0 we have not had any sort of
hard requirement for API compatibility and the language in this vote
changes that. My original response explained this in more detail in my
original explanation.
On Wed, Dec 3, 2014 at 5:33 PM, Keith Turner<ke...@deenlo.com> wrote:
On Wed, Dec 3, 2014 at 5:28 PM, John Vines<vi...@apache.org> wrote:
I stand by my -1. This vote would guarantee a level of API compatibility
that I don't think we should be held to.
Can you give some some specific reasons for your -1?
On Wed, Dec 3, 2014 at 5:15 PM, Christopher<ctubb...@apache.org> wrote:
Does this information affect your vote?
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Tue, Dec 2, 2014 at 6:16 PM, Christopher<ctubb...@apache.org>
wrote:
On Tue, Dec 2, 2014 at 5:18 PM, John Vines<vi...@apache.org> wrote:
On Tue, Dec 2, 2014 at 3:14 PM, Christopher<ctubb...@apache.org>
wrote:
On Tue, Dec 2, 2014 at 3:07 PM, John Vines<vi...@apache.org>
wrote:
-1 I do not like the idea of committing to 1.7.0-1.9.9... API
additions
for
the 2.0 API. We have already come to the consensus that 2.0 will
break
the
1.x API which provides a lot of breathing room and freedom from
old
decisions. This causes this issue to come roaring back and an even
larger
amount of scrutiny to be required for all 1.7.0-1.9.9... API
changes. I
would go so far as to say an undefinable amount of scrutiny since
we
still
don't have solid foundation of a 2.0 API. We cannot judge API
items
for
how
well they belong in an API that does not exist yet.
Honestly, I don't expect us to have any major 1.x releases after
1.7.x.
These guidelines would just add some minor protection, making 1.x a
bit
more stable in the transition to 2.0 if we ever do have such
releases.
I'd
hate for a user to seamlessly migrate to 2.0 from 1.7, but not be
able
to
seamlessly migrate from a 1.8 to 2.0, because 1.8 dropped some 1.7
API.
This doesn't make any sense. I've been under the impression that there
will
not be a seamless migration to 2.0 from any release. I thought 2.0 was
supposed to be a clean start of an API in order to prevent old method
signatures from making a better, cleaner API. And with that, it means
that
migrating from 1.7 shouldn't make any different from 1.8. I expect
there
to
be no necessity for any api in any version of 1.x to exist in 2.0,
including those introduced in 1.999.0 if that's what it takes. Your
statement specifies differently and that either means my bases for
2.0's
API is false or your now introducing a new requirement to it.
We're not just going to drop the 1.x API. The core jar will still
exist,
and contain all the old APIs (at least, that was my understanding). We
weren't going to throw out the window our normal practice of
deprecating
APIs (I certainly had no intentions to do so). My understanding would
be
that we would deprecate the old 1.x APIs in 2.0, and remove them in
3.0.
I've not even considered this as a "new requirement" for the new client
API... it's just the way we do things in this community (deprecate
first,
remove later). The only difference would be that the version numbers
would
actually mean something in terms of guarantees about when we remove
those
deprecated methods. This is what I've consistently expressed in the
previous thread regarding ACCUMULO-3176.
Tangential- I would like to see a clause about all current API
items
will
not be removed (still could be deprecated) until 2.0.0, as I feel
this
may
ease some concerns about API alteration in 1.7+.
I believe I expressed that above, and only excluded things that were
deprecated prior to 1.7 (such as aggregators, which I expect to
drop in
2.0).
On Tue, Dec 2, 2014 at 3:01 PM, Christopher<ctubb...@apache.org>
wrote:
Following the conversation on the [VOTE] thread for
ACCUMULO-3176,
it
seems
we require an explicit API guidelines at least for 1.7.0 and
later
until
2.0.0.
I hereby propose we adopt the following guidelines for future
releases
(if
we produce any such releases) until 2.0.0:
API additions are permitted in "major" 1.x releases (1.7, 1.8,
1.9,
1.10,
etc.).
API should be forwards and backwards compatible within a 1.x
release
(no
new additions to the API in a "bugfix" release; e.g. 1.7.1).
New API in 1.7.0 and later 1.x releases will not be removed in
2.0
(though
they may be deprecated in 2.0 and subject to removal in 3.0).
Existing API in 1.7.0 will be preserved through 2.0, and should
only be
subject to removal if it was already deprecated prior to 1.7.0
(though
they
may be deprecated in 2.0 and subject to removal in 3.0).
The purpose of these guidelines are to ensure the ability to add
additional
functionality and evolve API naturally, while minimizing API
disruptions
to
the user base, in the interim before 2.0.0 when we can formally
adopt
an
API/versioning policy.
Exceptions to these guidelines should be subject to a majority
vote,
on a
case-by-case basis.
Because these relate to release planning, this vote will be
subject to
majority vote, in accordance with our bylaws pertaining to
release
planning
and voting, and will be open for 3 days, concluding at 2000 on 5
Dec
2014
UTC.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
