[xwiki-devs] [VOTE] Changing our deprecation strategy (TAKE2)
Hi devs, I had started a first VOTE: http://markmail.org/thread/56v5thsj6wv7tpno But since that first VOTE transformed into a brainstorming I'm starting a new VOTE below with the result of our brainstorming: * Distribute without legacy modules by default * Document how users can add legacy modules and make that visible from the download page somewhere. * Move deprecated APIs to legacy modules as soon as our code is clean and stops using the newly deprecated APIs * Never remove APIs from the legacy modules by default but when we really need to do so (for some technical reason for example), do it on a case by case basis and send a VOTE to do so This ensures that: * New users quickly use the newest APIs (they won't even see the old APIs by default). * Older users are not broken since they can add the legacy modules * When someone upgrades he can easily try using the new distribution without legacy and if it breaks some of his code he can either fix his code or add the legacy modules Here's my +1 Thanks -Vincent
On 04/10/2012 12:21 PM, Vincent Massol wrote:
Hi devs,
I had started a first VOTE: http://markmail.org/thread/56v5thsj6wv7tpno
But since that first VOTE transformed into a brainstorming I'm starting a new VOTE below with the result of our brainstorming:
* Distribute without legacy modules by default * Document how users can add legacy modules and make that visible from the download page somewhere. * Move deprecated APIs to legacy modules as soon as our code is clean and stops using the newly deprecated APIs * Never remove APIs from the legacy modules by default but when we really need to do so (for some technical reason for example), do it on a case by case basis and send a VOTE to do so
This ensures that: * New users quickly use the newest APIs (they won't even see the old APIs by default). * Older users are not broken since they can add the legacy modules * When someone upgrades he can easily try using the new distribution without legacy and if it breaks some of his code he can either fix his code or add the legacy modules
Here's my +1
+1. -- Sergiu Dumitriu http://purl.org/net/sergiu/
+1 Thanks, Marius On Tue, Apr 10, 2012 at 7:21 PM, Vincent Massol <vincent@massol.net> wrote:
Hi devs,
I had started a first VOTE: http://markmail.org/thread/56v5thsj6wv7tpno
But since that first VOTE transformed into a brainstorming I'm starting a new VOTE below with the result of our brainstorming:
* Distribute without legacy modules by default * Document how users can add legacy modules and make that visible from the download page somewhere. * Move deprecated APIs to legacy modules as soon as our code is clean and stops using the newly deprecated APIs * Never remove APIs from the legacy modules by default but when we really need to do so (for some technical reason for example), do it on a case by case basis and send a VOTE to do so
This ensures that: * New users quickly use the newest APIs (they won't even see the old APIs by default). * Older users are not broken since they can add the legacy modules * When someone upgrades he can easily try using the new distribution without legacy and if it breaks some of his code he can either fix his code or add the legacy modules
Here's my +1
Thanks -Vincent _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
+1 Thanks On Wed, Apr 11, 2012 at 11:28, Marius Dumitru Florea < mariusdumitru.florea@xwiki.com> wrote:
+1
Thanks, Marius
On Tue, Apr 10, 2012 at 7:21 PM, Vincent Massol <vincent@massol.net> wrote:
Hi devs,
I had started a first VOTE: http://markmail.org/thread/56v5thsj6wv7tpno
But since that first VOTE transformed into a brainstorming I'm starting a new VOTE below with the result of our brainstorming:
* Distribute without legacy modules by default * Document how users can add legacy modules and make that visible from the download page somewhere. * Move deprecated APIs to legacy modules as soon as our code is clean and stops using the newly deprecated APIs * Never remove APIs from the legacy modules by default but when we really need to do so (for some technical reason for example), do it on a case by case basis and send a VOTE to do so
This ensures that: * New users quickly use the newest APIs (they won't even see the old APIs by default). * Older users are not broken since they can add the legacy modules * When someone upgrades he can easily try using the new distribution without legacy and if it breaks some of his code he can either fix his code or add the legacy modules
Here's my +1
Thanks -Vincent _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO
On Apr 10, 2012, at 6:21 PM, Vincent Massol wrote:
Hi devs,
I had started a first VOTE: http://markmail.org/thread/56v5thsj6wv7tpno
But since that first VOTE transformed into a brainstorming I'm starting a new VOTE below with the result of our brainstorming:
* Distribute without legacy modules by default * Document how users can add legacy modules and make that visible from the download page somewhere.
I'm having second thoughts about this item. All the other items are fine but this one is a bit harsh IMO. Imagine what will happen: users will download latest version, will try to install extensions and they'll fail badly with huge stack traces… (simply because most if not all of extensions not done by the XWiki dev team will contain deprecated calls). Thus, without any warnings, users will find a "non working XWiki", which is very bad both for the user and for XWiki's image. We want users to find XWiki to be a rock solid solution. Thus what I think would be better: * Step 0 (now): Keep releasing a distribution with legacy modules by default for the moment * Step 1: Work on our Wiki Console, i.e. the ability for people editing pages to see inside the wiki the places where they call deprecated apis. Also have a page somewhere listing all deprecated made throughout the wiki. Basically work on showing deprecated apis to users so that they **know** about them and can fix them. This is the first step in the awareness. * Step 1 bis: Work on providing a nice error message when a page calls a deprecated API that is not available in the wiki, explaining to the user how to contact his admin and how to install the legacy module required (even better, use the EM to install it at the click of a button). * Step 3: Provide a distribution without legacy modules. A second step could be to make that distribution the default but still make the legacy distribution visible so that it's easy for users to use it if they need to use extensions that use deprecated calls for example WDYT? Of course this strategy would need to be refined but the general gist is that we should still provide legacy modules till we've improved our way of showing, fixing and handling deprecated calls from wiki pages. Thanks -Vincent
* Move deprecated APIs to legacy modules as soon as our code is clean and stops using the newly deprecated APIs * Never remove APIs from the legacy modules by default but when we really need to do so (for some technical reason for example), do it on a case by case basis and send a VOTE to do so
This ensures that: * New users quickly use the newest APIs (they won't even see the old APIs by default). * Older users are not broken since they can add the legacy modules * When someone upgrades he can easily try using the new distribution without legacy and if it breaks some of his code he can either fix his code or add the legacy modules
Here's my +1
Thanks -Vincent
This vote is passed and I've modified our page at: http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HBackward... Thanks -Vincent On Apr 10, 2012, at 6:21 PM, Vincent Massol wrote:
Hi devs,
I had started a first VOTE: http://markmail.org/thread/56v5thsj6wv7tpno
But since that first VOTE transformed into a brainstorming I'm starting a new VOTE below with the result of our brainstorming:
* Distribute without legacy modules by default * Document how users can add legacy modules and make that visible from the download page somewhere. * Move deprecated APIs to legacy modules as soon as our code is clean and stops using the newly deprecated APIs * Never remove APIs from the legacy modules by default but when we really need to do so (for some technical reason for example), do it on a case by case basis and send a VOTE to do so
This ensures that: * New users quickly use the newest APIs (they won't even see the old APIs by default). * Older users are not broken since they can add the legacy modules * When someone upgrades he can easily try using the new distribution without legacy and if it breaks some of his code he can either fix his code or add the legacy modules
Here's my +1
Thanks -Vincent
participants (4)
-
Denis Gervalle -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol