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