Re: [xwiki-devs] [VOTE] Changing our deprecation strategy

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_versioningfor 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