On Jan 23, 2013, at 9:20 AM, Denis Gervalle <[email protected]> wrote: > Hi Vincent, > > I fully agree with you about the need to avoid breaking an interface, and > in particular, for a bugfix/stabilization release. However, > as Jerome pointed out, we probably need to have separate rules for SPI and > API. I know some interface can be both, and that the distinction is not > always clear, but as Jerome and previous discussion on young API have > suggested, annotating our interface would tells everyone our POV. It will > also ensure we have the same POV. With such information, we will surely > improve our flexibility and speed of development, which is IMO a key to > avoid obsolescence.
Indeed, we need to close that discussion. Thanks -Vincent > For the current case, IMO this interface was made as an API for third > parties, and not as an SPI. This is why I do not see augmenting it to be a > serious issue. Moreover, even if this interface was introduced in the 3.x > cycle, its real power was effectively put into application in the 4.x > cycle. So I still see it more as a "young" API in the 4.x cycle, than I > would in the 5.x. > > So, IMO, what should be evaluated here is: programatic access to a minor > new feature vs stability in an API. > I have definitely a preference for providing new possibilities when it does > not break current usage of an API. > > Thanks for having change your vote. > > > On Wed, Jan 23, 2013 at 8:17 AM, Vincent Massol <[email protected]> wrote: > >> >> On Jan 22, 2013, at 4:04 PM, Vincent Massol <[email protected]> wrote: >> >>> >>> On Jan 22, 2013, at 3:22 PM, Denis Gervalle <[email protected]> wrote: >>> >>>> Hi devs, >>>> >>>> For this one, I though it is trivial, but the rule being the rule, here >> is >>>> the vote to add the following exclusion: >>>> >>>> <difference> >>>> >> <className>com/xpn/xwiki/store/migration/DataMigrationManager</className> >>>> <method>com.xpn.xwiki.store.migration.DataMigrationStatus >>>> getDataMigrationStatus()</method> >>>> <differenceType>7012</differenceType> >>>> <justification>New method to allow building an UI for reporting >> migration >>>> issues (mainly for sub-wiki)</justification> >>>> </difference> >>>> >>>> Since I need it ASAP, will commit that one upfront, and I will revert if >>>> anyone disagree. >>>> >>>> Hope this works for you, here is my +1. >>> >>> I'm not convinced that we should break API in a bugfix release so I'm >> very very close to -1 to have this in 4.4.1 and close to -1 for 4.5M1 >> unless there's no other possibility for your use case in which case I'm +0. >> >> I'm changing my mind a little bit here. It's true that changing an API in >> a bugfix/stabilization release is not the best of ideas. However if we want >> to change it, pushing the change to 5.0 means that there are more risks >> that users will use the old API and thus be broken when they switch to 5.0. >> That said, since 5.0 is a new cycle it's normal that it has more >> incompatibility changes… >> >> In any case, changing my vote to +0. >> >> I haven't analyzed the change though (didn't get the time yet) and I hope >> it's worth it and that the API change was really required :) >> >> Thanks >> -Vincent >> >>> >>> Why do we need this API? Is that the only solution? >>> >>> Shouldn't we take that occasion to create a new xwiki-platform-migration >> module for migrations (and use the org.xwiki.migration package)? >>> >>> Shouldn't we wait for 5.0 to break this API since 4.4 and 4.5 are about >> stability releases? >>> >>> Thanks >>> -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
