So we just have a discussion about that with Vincent, mainly on the first point: we both agree on 2nd and 3rd point.
So now I see two options:
-
We agree that it’s ok to lose backward compatibility of the old API: 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.
-
We agree that we don’t want to break the backward compatibility 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.
I had not taken into account the first option when starting this proposal to respect our backward compatibility, now maybe in that specific case it could make sense to break it in order to keep the old name. Taking into account, that it’s also unlikely that many people uses the old API directly. So all in all, I’d be now in favor of solution 1.
I’m going to open a limited time vote for those options in a new thread so that we can move on on this topic.
[Edit: the vote is opened here: Drop backward compatibility on old Ratings API]