accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Wed, 03 Dec 2014 17:02:12 GMT
On Wed, Dec 3, 2014 at 9:48 AM, Sean Busbey <busbey@cloudera.com> wrote:

> -1 also, ATM. I'd like to see us freeze APIs between now and the 2.0
> release.
>
>
That's going to effectively block all new features until some point in the
future when 2.0 is ready. We have absolutely no idea when that will be. I
don't think we should freeze the API indefinitely like that. That seems
excessive, and is going to block existing work in progress slated for 1.7,
as well as many 1.7 additions that have already occurred. The only rational
way I can see this happening is if we rename 1.7 as 2.0, or if we postpone
2.0 until all the things we want in it are ready.


> 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.
>
>
Yes, the point of these proposed guidelines is to ensure that that risk is
low in the interim.


> 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.
>
>
Agreed. Forward compatibility is also nice to have. However, we cannot have
forward compatibility between "major" versions... that would block all new
features. Ensuring forward compatibility for the API at the bugfix level,
seems reasonable, though, and that's one of the arguments that was made by
several of us in past conversations about avoiding backporting features
(such as the ones you backported to 1.4; note: I mention that as an
example... not to hold you to some past opinion, as I recognize opinions
can change over time).


> I'd also like to see the "no removing of deprecated" language strengthened
> to remove the exception for things deprecated prior to 1.7.
>
>
So, the only things removed in 1.7 was the exceptional case of the
problematic Instance.getConfiguration(). So, this is already covered, as
long as we don't do any further removals (which I'm fine with) up to 2.0.
What I wouldn't want to do is include all the aggregator stuff in 2.0. The
only things dropped form 2.0 are stuff that were deprecated in 1.6 and
earlier. Anything deprecated in 1.7 would still exist, as deprecated, in
2.0, and until 3.0.


> 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.
>
>
We also have to consider users who need additional features and cannot fail
to deliver features/improvements, on the basis of a hypothetical future
version.


>
> On Tue, Dec 2, 2014 at 2:07 PM, John Vines <vines@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 <ctubbsii@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
>

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