13 Jan
2011
13 Jan
'11
1:13 p.m.
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?
Personally I'm fine and I'd like to add this caveat to the best practice if we
agree.
Thanks
-Vincent
13 Jan
13 Jan
1:59 p.m.
On 01/13/2011 07:13 AM, 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.
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
2:22 p.m.
On Thu, Jan 13, 2011 at 1:13 PM, Vincent Massol <vincent(a)massol.net> 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?
I agree with Caleb that we should obey our rule and remove deprecation
introduced in 2.4.x and before (3 majors).
Otherwise +1.
Thanks,
JV.
2:40 p.m.
On Jan 13, 2011, at 2:22 PM, Jean-Vincent Drean wrote:
On Thu, Jan 13, 2011 at 1:13 PM, Vincent Massol
<vincent(a)massol.net> wrote:
I don't think Caleb mentioned 2.4.x. Why not follow our rule and say 2.5.x? Are you
proposing to change our rules to 3 final releases rather than 2?
Thanks
-Vincent
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?
I agree with Caleb that we should obey our rule and remove deprecation
introduced in 2.4.x and before (3 majors). Otherwise +1.
Thanks,
JV.
2:58 p.m.
I completely misread, don't pay attention to my comment.
JV.
On Thu, Jan 13, 2011 at 2:40 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Jan 13, 2011, at 2:22 PM, Jean-Vincent Drean wrote:
On Thu, Jan 13, 2011 at 1:13 PM, Vincent Massol
<vincent(a)massol.net> wrote:
I don't think Caleb mentioned 2.4.x. Why not follow our rule and say 2.5.x? Are you
proposing to change our rules to 3 final releases rather than 2?
Thanks
-Vincent
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?
I agree with Caleb that we should obey our rule and remove deprecation
introduced in 2.4.x and before (3 majors). Otherwise +1.
Thanks,
JV.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
2:35 p.m.
On Thu, Jan 13, 2011 at 1:13 PM, Vincent Massol <vincent(a)massol.net> 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?
Personally I'm fine and I'd like to add this caveat to the best practice if we
agree.
+1, and I'd like to add it as a best practice for JavaScript as well.
Jerome.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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/
8:26 p.m.
On Jan 13, 2011, at 8:00 PM, Sergiu Dumitriu wrote:
On 01/13/2011 01:13 PM, Vincent Massol wrote:
Not sure what you mean by "nonsense".
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.
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
9:02 p.m.
On 01/13/2011 08:26 PM, Vincent Massol wrote:
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
On Jan 13, 2011, at 8:00 PM, Sergiu Dumitriu wrote:
$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.
On 01/13/2011 01:13 PM, Vincent Massol wrote:
Not sure what you mean by "nonsense". 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.
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
4995
days inactive
4995
days old
9 comments
5 participants
participants (5)
-
Caleb James DeLisle -
Jean-Vincent Drean -
Jerome Velociter -
Sergiu Dumitriu -
Vincent Massol