accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: [VOTE] API release policy for 1.7/2.0
Date Wed, 03 Dec 2014 14:51:41 GMT
On Tue, Dec 2, 2014 at 5:16 PM, Christopher <ctubbsii@apache.org> wrote:

> On Tue, Dec 2, 2014 at 5:18 PM, John Vines <vines@apache.org> wrote:
>
> > On Tue, Dec 2, 2014 at 3:14 PM, Christopher <ctubbsii@apache.org> wrote:
> >
> > > On Tue, Dec 2, 2014 at 3: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.
> > > >
> > > >
> > > 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.
>
>
>
FWIW, I think the "new requirement" John is speaking of is for the 2.0 API
to include deprecated support for pre-2.0 APIs.

I was also under the understanding that our plan for 2.0 was to make a
clean break on APIs to make it easier to maintain strong compatibility
promises going forward.

I'm not sure if this changes my positions since it draws out the timeline
of effort for those migrating to 2.0 rather than remove  it.. Next time
let's have a DISCUSS thread prior to calling a vote so I have more time to
think.

-- 
Sean

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