On 10 Feb 2014 at 13:55:09, Denis Gervalle
(d...@softec.lu(mailto:d...@softec.lu)) wrote:
> On Sun, Feb 9, 2014 at 6:03 PM, vinc...@massol.net wrote:
>
> >
> >
> >
> >
> > On 4 Feb 2014 at 16:14:41, vinc...@massol.net (vinc...@massol.net(mailto:
> > vinc...@massol.net)) wrote:
> >
> > > Note: be careful that you might have added new APIs in a class already
> > having an @Unstable annotation at the class level and thus when you remove
> > that class level annotation you might have to add new @Unstable annotations
> > at the method level if those methods were added/modified in 5.x or later.
> >
> >
> > Actually this is not correct!
> >
> > The @Unstable marks the first time an API is introduced. All API changes
> > that happen after are stabilization of the first version of the API and
> > this what counts is the first time the API was introduced and after 1 full
> > cycle, we need to remove the @Unstable annotation.
> >
> > For example:
> > - Git module API was first introduced in 4.2M1 (@Unstable was thus added
> > at the time)
> > - Then in 5.3M1 the package was modified
> > - And in 5.3M2 3 new methods were added
> >
> > Consequence: in 6.0 we now consider the Git module API as stable since
> > it’s been more than 1 full cycle since it was first introduced. This means
> > that from now on, if we wish to modify this API we need to ensure we don’t
> > break the backward compatibility or we’ll need to send a VOTE if we want to
> > break it and explain why we wish to break it and why there’s no other
> > solution, to try to convince the other committers.
> >
>
> While I agree with your point, I do not see why we could not add new
> methods, or keep some recent methods with an @unstable flag. Adding new
> method does not necessarily break an API IMO.
I agree of course. For interfaces this cannot happen but for classes it’s
possible to add a new method without breaking backward compatibility.
Thanks
-Vincent
> > Thanks
> > -Vincent
> >
> > > Thanks
> > > -Vincent
> > >
> > > On 4 Feb 2014 at 16:11:04, vinc...@massol.net (vinc...@massol.net
> > (mailto:vinc...@massol.net)) wrote:
> > >
> > > > ok I’ve done a full review and here’s the results of unstable
> > annotations to remove:
> > > >
> > > > * commons-job module. Owner: Thomas
> > > > * platform-git mpdule (GitScriptService). Owner: Vincent
> > > > * platform-legacy-url. Owner: Vincent
> > > > * platform-localization. Owner: Thomas
> > > > * platform-solr (SolrConfiguration, SolrInstance,
> > SolrIndexScriptService). Owner: Marius
> > > > * platform-url. Owner: Vincent
> > > >
> > > > Could each “owner" please remove the @Unstable annotations found
> > inside classes in the above-mentioned modules when the @since is before
> > 5.0M1?
> > > >
> > > > Thanks
> > > > -Vincent
> > > >
> > > > On 31 Jan 2014 at 08:51:58, Thomas Mortagne (thomas.morta...@xwiki.com
> > (mailto:thomas.morta...@xwiki.com)) wrote:
> > > >
> > > > > It's not a threat :)
> > > > >
> > > > > It's actually the opposite here: the point is to indicate that an API
> > > > > is not unstable anymore and cannot be broken (this kind of annotation
> > > > > did not exist in 3.x).
> > > > >
> > > > > On Fri, Jan 31, 2014 at 8:48 AM, Paul Libbrecht wrote:
> > > > > > Vincent,
> > > > > > is there a clickable list?
> > > > > > A way for a project that links to an older xwiki (e.g. we link to
> > xwiki 3.5) to know that things are threatened?
> > > > > >
> > > > > > thanks
> > > > > >
> > > > > > paul
> > > > > >
> > > > > >
> > > > > > Le 31 janv. 2014 à 08:44, "vinc...@massol.net" a écrit :
> > > > > >> According to your rules since we're starting a new cycle we need
> > to review all existing @Unstable annotations and remove ones that have been
> > there for at least one cycle (i.e. prior to the 5.x cycle).
> > > > > >>
> > > > > >> See
> > http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#H40UnstableAnnotation
> > > > > >>
> > > > > >> It's also the occasion to check @Unstable APIs that we can
> > consider stable now.
> >
_______________________________________________
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
