On Fri, Feb 8, 2013 at 7:15 PM, Vincent Massol <[email protected]> wrote:
On Feb 8, 2013, at 7:09 PM, Denis Gervalle <[email protected]> wrote:
On Fri, Feb 8, 2013 at 3:58 PM, Vincent Massol <[email protected]> wrote:
On Feb 8, 2013, at 3:42 PM, Denis Gervalle <[email protected]> wrote:
By the way, if we agree on @unstable, I also think having another annotation for marking stable API that are not considered to be stable SPI. Why not something like @onlyAPI or @unstableSPI on an interface ?
I think first we need to define what is an SPI and what is an API first. ATM I don't think I understand clearly the difference in the context of XWiki. Is it clear for you?
I do not really understand your question. The general definition is rather clear: "Service Provider Interface (SPI) is an API intended to be implemented or extended by a third party".
All our component interfaces are meant to be implemented by 3rd parties to override default behaviors. Are they SPI?
If you consider them stable enough, these could be. The distinction is clearly based of what we think of it. Let me take an example: interface DataMigrationManager (do not mixup with DataMigration which is an SPI for sure). Currently, I consider this one as an API, but I do not imagine any serious usage of it as an SPI for a third party. Marking it API only, would clearly state this point of view. It means that adding a new method to this interface is not considered a breakage. Anyone which would implement it, knows it could have his code broken later.
What I would like to be annotated is API that we do not consider stable SPI at the moment. It is less restrictive than @unstable, but more than not saying anything. Is that answering your question ?
That seems complex. Why not use @unstable on "SPI" classes/methods?
Because the status is about the interface as a whole. It is particularly about adding new methods (or signatures of existing methods), while existing methods are stable. I do not want to add something new, but to state clearly what we think of our interfaces. This is already the case, while we do not really state it. Considering anything an SPI is not an option IMO, since it will create more complexity over time, for a very low benefit, since the chances of a third party to implement an interface like the DataMigrationManager is near zero. And if any, this third party will surely agree to apply some minor changes to its implementation when needed. All that said, I wonder if it wouldn't be better to annotate SPI interface in place of non-SPI one, with a @SPI annotation. Which will favor API only and limit complexity. A user really interested in implementing a not annotated interface could easily open an issue explaining his use case, so we may open the interface as an SPI.
Thanks -Vincent
Thanks -Vincent
On Fri, Feb 8, 2013 at 3:30 PM, Thomas Mortagne <[email protected]>wrote:
Yes it's more clear than "beta".
On Fri, Feb 8, 2013 at 3:28 PM, Denis Gervalle <[email protected]> wrote:
+1, but I have the impression that @unstable would be more meaningful
On Fri, Feb 8, 2013 at 2:49 PM, Thomas Mortagne <[email protected]>wrote:
> On Fri, Feb 8, 2013 at 2:40 PM, Vincent Massol <[email protected]> wrote: >> Hi Paul, >> >> On Feb 8, 2013, at 1:22 PM, Paul Libbrecht <[email protected]> wrote: >> >>> Doesn't the @deprecated annotation actually does exactly the job? >>> (except it has to be interpreted as meaning something else than "old > code", but "do not use code"). >> >> @Deprecated means something different. It's about some code that you > shouldn't use because we no longer think it's good to use and it's going to > be removed in the future. >> >> This is not what a @beta or @experimental annotation would mean. They > would mean "this is a new api that you can use but it's not stable yet and > may change in the future so be prepared to update your code if that > happens". > > Plus @deprecated is technically pretty stable API while @beta can be > broken anytime. > >> >> Thanks >> -Vincent >> >>> paul >>> >>> >>> On 8 févr. 2013, at 12:45, Thomas Mortagne wrote: >>> >>>>> * Proposal 1 (internal package): >>>>> - Vincent >>>>> - Marius >>>>> >>>>> * Proposal 2 (experimental package) >>>>> - Caleb >>>>> >>>>> * Proposal 3 (@Beta/@Experimental annotation) >>>>> - Thomas >>>>> - Edy >>>>> >>>>> * Other proposal >>>>> - Denis (use 1) for small changes and only use RN to mark new module > as experimental)
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO