Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Hadoop >> mail # dev >> [VOTE] Should we freeze the public stable APIs after 0.21.0?


Copy link to this message
-
Re: [VOTE] Should we freeze the public stable APIs after 0.21.0?

On Sep 25, 2009, at 10:36 AM, Philip Zeyliger wrote:

> I did a quick grep, and--perhaps I'm missing something--no  
> interfaces are
> currently marked as InterfaceStability.Stable.  FileContext is the  
> only
> interface that uses the org.apache.hadoop.classification package.
>  (Well, QueueManagerTestUtils has it commented out...)
> Do you have a proposed list of classes to be marked
> @InterfaceStability.Stable?
>
Yes, please see
https://issues.apache.org/jira/browse/HADOOP-5073?focusedCommentId=12664679&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel
#action_12664679

There is a proposal at the bottom of that comment.
(there have been a few changes proposed in that jira but that proposed  
tagging is mostly intact. I will update it shortly.)
>
> I think your question is whether we are committed to keeping the  
> APIs marked
> as stable in the course of 0.22 development to remain so through  
> 1.0.  (You
> wrote 0.21.0 below, but you probably meant 0.22.0.)  Yes, +1.
>
> What's our commitment to methods that are @Deprecated within 0.22's
> @InterfaceStability.Stable classes?  (I don't know that there are  
> any, but I
> bet there are or will be.)
>
> -- Philip
>
>
> On Fri, Sep 25, 2009 at 10:16 AM, Owen O'Malley <[EMAIL PROTECTED]>  
> wrote:
>
> > We are getting closer to being able to release a Common/HDFS/
> MapReduce 1.0.
> > I'd hope that we'll get the last set of things in to 0.22 that  
> mean that it
> > would be labelled 1.0. Toward that end, I'd like to start locking  
> down the
> > APIs that we've marked as public stable. What that would mean is  
> that any
> > interface that is tagged with the @InterfaceStability.Stable and
> > @InterfaceAudience.Public in the 0.21.0 release should not have  
> any changes
> > committed that require a recompilation of client code. This will  
> provide a
> > stable basis for our users' applications and reduce the costs of  
> upgrades.
> >
> > Clearly, I'm +1.
> >
> > -- Owen
> >
>