I agree, I don't see a point in freezing the APIs between now and 2.0.
Although, I think slightly stronger wording could be beneficial.
I don't see any pain in adding new API methods. If the old ones are
still there, there's no potential for pain for users to keep using what
they have been.
The only way I'm seeing to cause users unnecessary pain would be to
follow our "current" deprecation removal "rules". I am fine with not
performing any deprecation removals between now and 2.0 since 2.0 is
essentially a mass deprecation of any API we have before then.
And, for context, if this no-new-API freeze does stick, you would be
posthumously forcing us to go back and rip out a bunch of already
committed code for the replication feature and (possibly) the port to
HTrace. That would be pointless and a waste of time IMO.
Brian Loss wrote:
I disagree on freezing the API before 2.0. For one, it seems to indicate a
shift in policy over what a major release means if we’ve previously said that
API changes are allowed in 1.x releases. More important, if we’re looking at
potentially disruptive changes in the API for 2.0 (for example, I believe John
Vines said he didn’t expect the transition to 2.0 to be seamless), it means
integrators may take a long time to adopt it. Many might even avoid 2.0 to wait
for 2.1 to wait for things to stabilize after the “big changes” in 2.0. My
project, for example, might not be able to upgrade to the 2.x line for a very
long time for just that reason plus some other factors beyond our control. I
believe “forcing” people to decide on 2.0 by abandoning the addition of
features in the 1.x line is just the wrong way to go.
Sean makes the argument that porting backwards is just as difficult as porting
forwards in our code. That is certainly true, but I don’t see how that’s a
reason to avoid all API changes. Take the hypothetical case he provides of an
integrator that gets a regulatory requirement to use an earlier version. Why is
it more likely that this requirement would dictate they go from 1.7 to 1.6
instead of from 1.7 to 1.3? What if the integrator already used new features
that are currently in 1.7? It seems to me there’s no way to prevent that
potential pain in this hypothetical situation. We have a very real situation
where preventing API additions to 1.7 can cause problems for our integrators.
In fact it already has in the case of ACCUMULO-3176 since we wanted the feature
it provides for my project.
I agree that there will be temptation to squeeze out just one more release
before 2.0, but I’d rather it be a little harder on us instead of making it
easier on ourselves at the expense of alienating users. Sure these users could
backport features they need, but if they’re only going to be coming from the
2.0 line with a very different API, backporting may be a lot of work.
On Dec 3, 2014, at 9:48 AM, Sean Busbey<bus...@cloudera.com> wrote:
-1 also, ATM. I'd like to see us freeze APIs between now and the 2.0
release.
Downstream users have to plan when they invest effort in migrating Accumulo
versions. We've already signaled that 2.0 will be the start of a new API
with long-lived compatibility promises. (We should keep signaling this.)
That makes it a promising place to make a jump (in some cases, from 1.4 I'm
sure).
I would like to avoid, however possible, leaning those users towards
ignoring releases between now and 2.0. For those who are back on 1.4 or 1.5
we can't really do too much. For those on 1.6 we can make it so there is
relatively little risk in moving forward.
API additions matter here because when a system integrator makes an
application on top of Accumulo they often start at the latest version they
can find. Later, they may have a client with a regulatory requirement to
use an earlier version. Porting backwards is just as hard as porting
forwards in our code base.
I'd also like to see the "no removing of deprecated" language strengthened
to remove the exception for things deprecated prior to 1.7.
Yes, this will severely constrain what we can do prior to 2.0. But I think
doing otherwise will just encourage us to keep squeezing in "just one more"
major pre-2.0 release to get some additional client facing feature out the
door.
If we have some downstream users with different compatibility needs and
with particular operational needs for features that are delayed to 2.0
because of this decision, it should be straight forward for them to
backport the things they need and run their own packaging. Plenty of folks
who don't need the legal indemnification that the ASF provides do this for
a wide variety of projects.
On Tue, Dec 2, 2014 at 2: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.
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+.
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
--
Sean
