13 Jan
2011
13 Jan
'11
2:10 p.m.
On Jan 13, 2011, at 1:59 PM, Caleb James DeLisle wrote:
Yes we've added compat configuration in the past. We'll need to think about
removing those too at some point (like the title compat switch) ;)
Thanks
-Vincent
On 01/13/2011 07:13 AM, Vincent Massol wrote:
2.5.x ---- 2.6 ---- 2.7 ---- 3.0
2 numbers is 2.6 and 2.7.
There's the major argument but I feel it's better to leave some time for
developers to upgrade and have a chance to fix deprecation that were added recently.
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.
I would go as far as to say <= 2.7 since it is 2 numbers back and 3.0 is a
"major" revision. 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?
+1 it's not fun but our hands are tied here IMO.
For some cases esp. where compatibility and security are at odds, perhaps we should add
a
compatibility switch? WDYT? Caleb
>
> Personally I'm fine and I'd like to add this caveat to the best practice if
we agree.
>
> Thanks
> -Vincent