23 Jan
2013
23 Jan
'13
9:20 a.m.
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 <vincent(a)massol.net> wrote:
On Jan 22, 2013, at 4:04 PM, Vincent Massol <vincent(a)massol.net> wrote:
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
--
Denis Gervalle
SOFTEC sa - CEO
eGuilde sarl - CTO
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
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs