On 01/13/2011 08:26 PM, Vincent Massol wrote: > > On Jan 13, 2011, at 8:00 PM, Sergiu Dumitriu wrote: > >> 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#HDeprecationStrategy >>> >>> " >>> 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? > > Not sure what you mean by "nonsense".
$doc.getFormat() which doesn't work at all. It's not even @Deprecated, but I doubt anyone even knows it's there. $doc.getArchive() which returns serialized RCS diff with no tools to process it. These are also nonsense IMO, but they might be used, so they should be deprecated for the moment: $doc.getRCSVersion() which returns implementation details. $doc.getRCSVersion() which returns implementation details. $doc.getLastChanges() which returns implementation details. >> 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. > > For me privileged API are ok since otherwise everything is script public. > > OTOH removing velocity APIs is not really ok for me at this point in time > since we don't have a way to notify users that they're using a deprecated API > right now. We need that first before we can think about removing them IMO. > >> Personally I prefer to prune out even some public methods, on a >> case-by-case decision. > > Sure but 1) we need some general canvas to work with since asking every time > is a bit painful and 2) no committer seem to be removing deprecated methods > (we have so many old ones in lots of places). > > The consensus so far was that we have rules but we don't apply them. My mail > was just there to agree to change that consensus with 3.0. > > Thanks > -Vincent >> >>> 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/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
