10 Feb
2014
10 Feb
'14
1:59 p.m.
On 10 Feb 2014 at 13:55:09, Denis Gervalle (dgl@softec.lu(mailto:dgl@softec.lu)) wrote:
On Sun, Feb 9, 2014 at 6:03 PM, vincent(a)massol.net
wrote:
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
On 4 Feb 2014 at 16:14:41, vincent(a)massol.net (vincent(a)massol.net(mailto:
vincent(a)massol.net)) wrote:
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. 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.
> Thanks
> -Vincent
>
> > Thanks
> > -Vincent
> >
> > On 4 Feb 2014 at 16:11:04, vincent(a)massol.net (vincent(a)massol.net
> (mailto:vincent@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.mortagne(a)xwiki.com
> (mailto:thomas.mortagne@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, "vincent(a)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#H40Unsta…
> > > > >>
> > > > >> It's also the occasion to check @Unstable APIs that we
can
> consider stable now.
>