[xwiki-devs] [VOTE] Add CLIRR exclude for 1 new method in DataMigrationManager interface for 4.4.1 and 4.5M1
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. -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
+1 On Tue, 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.
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
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. 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
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
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 <[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
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
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
+0 Thanks, Marius On Tue, Jan 22, 2013 at 4: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.
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (4)
-
Denis Gervalle -
Marius Dumitru Florea -
Thomas Mortagne -
Vincent Massol