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