Drop backward compatibility on old Ratings API

Hi everyone,

as part of the proposal for a new Ratings API (available there: https://forum.xwiki.org/t/new-api-for-ratings/7418), there was lots of discussions about the name of the new Rating API to use, in order to preserve the backward compatibility.

Now after discussing it further, I’m now thinking that we could benefit to actually drop the backward compatibility.
So here are the two options I’m proposing, don’t hesitate to read the original proposal to see the details:

  1. We agree that it’s ok to lose backward compatibility of the old Ratings API once moved in attic: in that case, we can reuse “ratings” naming everywhere. It would mean that any developer who would have used the old API and who would want to keep using it, could do so by manually installing the old API (we would provide it with a new name, and we could still have bug fixes on it). Now the old API wouldn’t be compatible with the new one, so he wouldn’t have both API on same wiki. Pros: we keep the old name, for most user the change will be transparent. Cons: we break the backward compatibility and users of the old API won’t have any other choice on the long term than updating to the new API.

  2. We agree that we don’t want to break the backward compatibility when moving the old API to attic, and developers using the old API should be able to keep using it, along with the new API in the same wiki. In that case we don’t have any other choice than chosing a new name for this new API. And we come back on the previous debate about which name to use.

This vote is open for one week until 22nd of September. Here’s my +1 for option 1.
[Edit: since this vote still doesn’t have receive any vote I’m extending it to friday 25th of September]

I’d prefer to let users of the old Ratings API provide feedback about this first.

Hi, +1 to drop the backward compatibility. Yet the migration should be planned as you already discussed.
This being done, big users of the old extension will have the pleasure to recover their data, discover new features and better performance in the new extension. Thanks Simon!

Hello Simon,

OK to drop compatibility and reuse the name for a better API.

I think it’s an API that is too little used as an API (except for the ratings application) to be worth inventing a new forced name for the better API.

However, as I discussed with Simon on a different channel, if it’s possible to preserve the same names as in the old API and as much as possible the same signatures for the functions that still make sense in the new ratings, it would be great, it would make code easily upgradable, if needed.

Also, as was already mentioned, this API breakage should be completely independent from the ratings data itself: upon upgrade, the ratings data of a wiki should be preserved and accessible with the new API.


Hi, thanks for those feedbacks. I’ll extend a last time the deadline to this vote until next wednesday (30th of september) to be sure anyone had a chance to vote on it, but then I’ll proceed.

+1 for 1, I doubt think this API ever been used much in extensions

Closing this vote today. I see 4 votes +1 for proposal 1 and no other votes.

So I will drop the backward compatibility on old Ratings API in favor of reusing its name for the new API. Thanks for all the feedbacks.