13 Jan
2011
13 Jan
'11
8 p.m.
On 01/13/2011 01:13 PM, Vincent Massol wrote:
Hi devs,
I think the start of the XE 3.x cycle is a good time to remove some deprecated
methods/classes.
We have a deprecation strategy defined already:
http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HDepreca…
"
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).
"
So 2 final releases mean that deprecations introduced in 2.5.x or before can
theoretically be removed for XE 3.0 final.
However, IMO we shouldn't remove deprecated methods/classes that are public for
scrips since this will break xwiki users.
Are we ok to do that?
Where's the limit between public and complete nonsense? There are
"public" methods in our APIs that aren't really used, and there are
internal methods that have been deprecated for some time but are still
widely used internally.
Plus, Groovy means scriptable as well, but it can access even non-public
APIs.
Personally I prefer to prune out even some public methods, on a
case-by-case decision.
Personally I'm fine and I'd like to add this
caveat to the best practice if we agree.
Thanks
-Vincent
--
Sergiu Dumitriu
http://purl.org/net/sergiu/