Hi devs,
I'd like to change our deprecation strategy. Here's what we are currently supposed
to use (we voted it a long time ago):
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HDepreca…
"
In addition our rule is to keep @deprecated methods/classes for 2 final releases after the
version where they were first added has been released as final.
For example if a method is deprecated in, say XE 1.3M2 then the method will be removed in
1.6M1 or after. Of course any major new release can deprecate anything. For example a
XWiki 2.0 release is allowed to break backward compatibility (obviously we need to be
careful to offer a migration path for users of previous major versions).
"
Issues:
* This seems a bit harsh to me for some of our users/devs in the community.
* We're not following which proves to me it's not a good rule
* It doesn't say anything about Scripting APIs which require a greater stability in
order not to break all wiki pages
Definition of a Scripting API:
* a Script Service (that's the new way of providing script apis)
* a class in the "api" package in xwiki-platform-oldcore (this is the old way of
providing script apis)
Thus I'd like to propose this new rule:
* Deprecated methods can only be removed in the next Release Cycle. For example something
deprecated in version N.x can be removed in version N+1.y where x and y can be anything.
This is logical since N+1 means a new major release and it's common to understand that
major releases have no guarantee of API compatibility (See
http://en.wikipedia.org/wiki/Software_versioning for example).
* For scripting APIs we can remove deprecated API only after 4 Release Cycles. For example
since we're in 4.x this means we can remove deprecated APIs from 0.x releases. And
when we start 5.x we will be able to remove deprecated scripting apis deprecated in 1.x.
Here's my +1
Thanks
-Vincent