On Jan 22, 2013, at 3:22 PM, Denis Gervalle <dgl(a)softec.lu> wrote: 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.

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

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.

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 &lt;vincent(a)massol.net&gt; wrote: > > On Jan 22, 2013, at 4:04 PM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: > >> >> On Jan 22, 2013, at 3:22 PM, Denis Gervalle &lt;dgl(a)softec.lu&gt; 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