Hi all,
I have been talking to many third-party yas part of my WMF internship in the last few weeks and one the main concerns they express is the lack of stability in the PHP classes MediaWiki exposes from version to version. The frequent changes in what I would call the PHP-API makes extentions developement and maintenance much more difficult with compatibility from version to version becoming a problem. Solving the problem would probably result in the development of more extensions, easier maintenance, less hacks to core and more users upgrading to the latest MediaWiki version. I am sure WMF developers are facing similar issues especially with projects like WikiData going on.
My question is: With the given technical heritage that MediaWiki carries, is it possible to have a (relatively) stable set of PHP classes defined, with a pledge not to change them in the next X releases or at least with some longer deprecation time? What would maintaining such a PHP-API entail? How difficult is it given the vast number of dependancies in MediaWiki code? Does it require restructuring a lot of the current core code? Do you think it should be a definite goal for WMF?
Thank you.
Mariya
Mariya,
Could you be more specific? What types of changes caused extensions to break? I might be mistaken but the vast majority of the API framework classes have been established over 5 years ago, with very few breaking changes since. Most changes were related to adding new functionality (new actions, new query submodules, new parameters), but that shouldn't have significantly affected extension development.
I do plan to introduce a few breaking changes (majority of the extensions should not be affected) in 1.21, such as the introduction of versioning, further modularization to allow pageset reuse, etc. See http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
Please note that in a rare case some features might be purposefully removed due to the security or scalability issues.
--Yuri
On Mon, Feb 11, 2013 at 7:58 AM, Mariya Nedelcheva Miteva < mariya.miteva@gmail.com> wrote:
Hi all,
I have been talking to many third-party yas part of my WMF internship in the last few weeks and one the main concerns they express is the lack of stability in the PHP classes MediaWiki exposes from version to version. The frequent changes in what I would call the PHP-API makes extentions developement and maintenance much more difficult with compatibility from version to version becoming a problem. Solving the problem would probably result in the development of more extensions, easier maintenance, less hacks to core and more users upgrading to the latest MediaWiki version. I am sure WMF developers are facing similar issues especially with projects like WikiData going on.
My question is: With the given technical heritage that MediaWiki carries, is it possible to have a (relatively) stable set of PHP classes defined, with a pledge not to change them in the next X releases or at least with some longer deprecation time? What would maintaining such a PHP-API entail? How difficult is it given the vast number of dependancies in MediaWiki code? Does it require restructuring a lot of the current core code? Do you think it should be a definite goal for WMF?
Thank you.
Mariya _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I believe Mariya is talking about the internal APIs available to extensions, (eg: User, Title, EditPage, so forth), not the public API.
Yay, acronyms!
-Chad
On Mon, Feb 11, 2013 at 8:14 AM, Yuri Astrakhan yuriastrakhan@gmail.com wrote:
Mariya,
Could you be more specific? What types of changes caused extensions to break? I might be mistaken but the vast majority of the API framework classes have been established over 5 years ago, with very few breaking changes since. Most changes were related to adding new functionality (new actions, new query submodules, new parameters), but that shouldn't have significantly affected extension development.
I do plan to introduce a few breaking changes (majority of the extensions should not be affected) in 1.21, such as the introduction of versioning, further modularization to allow pageset reuse, etc. See http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
Please note that in a rare case some features might be purposefully removed due to the security or scalability issues.
--Yuri
On Mon, Feb 11, 2013 at 7:58 AM, Mariya Nedelcheva Miteva < mariya.miteva@gmail.com> wrote:
Hi all,
I have been talking to many third-party yas part of my WMF internship in the last few weeks and one the main concerns they express is the lack of stability in the PHP classes MediaWiki exposes from version to version. The frequent changes in what I would call the PHP-API makes extentions developement and maintenance much more difficult with compatibility from version to version becoming a problem. Solving the problem would probably result in the development of more extensions, easier maintenance, less hacks to core and more users upgrading to the latest MediaWiki version. I am sure WMF developers are facing similar issues especially with projects like WikiData going on.
My question is: With the given technical heritage that MediaWiki carries, is it possible to have a (relatively) stable set of PHP classes defined, with a pledge not to change them in the next X releases or at least with some longer deprecation time? What would maintaining such a PHP-API entail? How difficult is it given the vast number of dependancies in MediaWiki code? Does it require restructuring a lot of the current core code? Do you think it should be a definite goal for WMF?
Thank you.
Mariya _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Yes, precisely. Is there an accepted way to call it, so I don't confuse people every time I talk about it ?
Yuri, I am working on getting some concrete examples.
Mariya
On Mon, Feb 11, 2013 at 3:24 PM, Chad innocentkiller@gmail.com wrote:
I believe Mariya is talking about the internal APIs available to extensions, (eg: User, Title, EditPage, so forth), not the public API.
Yay, acronyms!
-Chad
On Mon, Feb 11, 2013 at 8:14 AM, Yuri Astrakhan yuriastrakhan@gmail.com wrote:
Mariya,
Could you be more specific? What types of changes caused extensions to break? I might be mistaken but the vast majority of the API framework classes have been established over 5 years ago, with very few breaking changes since. Most changes were related to adding new functionality (new actions, new query submodules, new parameters), but that shouldn't have significantly affected extension development.
I do plan to introduce a few breaking changes (majority of the extensions should not be affected) in 1.21, such as the introduction of versioning, further modularization to allow pageset reuse, etc. See http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
Please note that in a rare case some features might be purposefully
removed
due to the security or scalability issues.
--Yuri
On Mon, Feb 11, 2013 at 7:58 AM, Mariya Nedelcheva Miteva < mariya.miteva@gmail.com> wrote:
Hi all,
I have been talking to many third-party yas part of my WMF internship in the last few weeks and one the main concerns they express is the lack of stability in the PHP classes MediaWiki exposes from version to version.
The
frequent changes in what I would call the PHP-API makes extentions developement and maintenance much more difficult with compatibility from version to version becoming a problem. Solving the problem would
probably
result in the development of more extensions, easier maintenance, less hacks to core and more users upgrading to the latest MediaWiki version.
I
am sure WMF developers are facing similar issues especially with
projects
like WikiData going on.
My question is: With the given technical heritage that MediaWiki
carries,
is it possible to have a (relatively) stable set of PHP classes defined, with a pledge not to change them in the next X releases or at least with some longer deprecation time? What would maintaining such a PHP-API
entail?
How difficult is it given the vast number of dependancies in MediaWiki code? Does it require restructuring a lot of the current core code? Do
you
think it should be a definite goal for WMF?
Thank you.
Mariya _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Maria: see http://www.mediawiki.org/wiki/API:Calling_internally for info on calling the api internally.
However thinking about it the interface is not really well designed for calling internally. One would expect a high level internal api would be returning title objects. One would not expect such an api to require you to have fake request objects. There is no documentation about which api methods are safe to call from a parser hook extension. There are several that are not.
Last of all, it doesnt really solve the problem maria brought up. The api called internally can really only act as a high level way to query the db. The db related methods are some of the most stable methods in all of mediawiki. Using the api might isolate you from certain db schema change But realistically non backwards compatible db changes are exceedingly rare.
-bawolff
On 2013-02-11 10:01 AM, "Maria Miteva" mariya.miteva@gmail.com wrote:
Yes, precisely. Is there an accepted way to call it, so I don't confuse people every time I talk about it ?
Yuri, I am working on getting some concrete examples.
Mariya
On Mon, Feb 11, 2013 at 3:24 PM, Chad innocentkiller@gmail.com wrote:
I believe Mariya is talking about the internal APIs available to extensions, (eg: User, Title, EditPage, so forth), not the public API.
Yay, acronyms!
-Chad
On Mon, Feb 11, 2013 at 8:14 AM, Yuri Astrakhan <yuriastrakhan@gmail.com
wrote:
Mariya,
Could you be more specific? What types of changes caused extensions to break? I might be mistaken but the vast majority of the API framework classes have been established over 5 years ago, with very few breaking changes since. Most changes were related to adding new functionality
(new
actions, new query submodules, new parameters), but that shouldn't
have
significantly affected extension development.
I do plan to introduce a few breaking changes (majority of the
extensions
should not be affected) in 1.21, such as the introduction of
versioning,
further modularization to allow pageset reuse, etc. See http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
Please note that in a rare case some features might be purposefully
removed
due to the security or scalability issues.
--Yuri
On Mon, Feb 11, 2013 at 7:58 AM, Mariya Nedelcheva Miteva < mariya.miteva@gmail.com> wrote:
Hi all,
I have been talking to many third-party yas part of my WMF
internship in
the last few weeks and one the main concerns they express is the
lack of
stability in the PHP classes MediaWiki exposes from version to
version.
The
frequent changes in what I would call the PHP-API makes extentions developement and maintenance much more difficult with compatibility
from
version to version becoming a problem. Solving the problem would
probably
result in the development of more extensions, easier maintenance,
less
hacks to core and more users upgrading to the latest MediaWiki
version.
I
am sure WMF developers are facing similar issues especially with
projects
like WikiData going on.
My question is: With the given technical heritage that MediaWiki
carries,
is it possible to have a (relatively) stable set of PHP classes
defined,
with a pledge not to change them in the next X releases or at least
with
some longer deprecation time? What would maintaining such a PHP-API
entail?
How difficult is it given the vast number of dependancies in
MediaWiki
code? Does it require restructuring a lot of the current core code?
Do
you
think it should be a definite goal for WMF?
Thank you.
Mariya _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 02/11/2013 09:50 AM, Brian Wolff wrote:
Maria: see http://www.mediawiki.org/wiki/API:Calling_internally for info on calling the api internally.
I think you're misunderstanding what she's saying. She's talk about ordinary PHP classes, methods and hooks, basically the way an extension normally talks to core.
Matt Flaschen
I don't think she means what we call the api - but more methods random extensions are likely to use.
We could start documenting certain stable methods with a special code comment ( say @stable) which would mean something like this method will not be removed, and if the need arises we'll remove the @stable and wait 2 versions before removing the method. Key candidates for this would include title::newFromText, parser::recursiveTagParse, etc. Ideally one would wait for the method to stand the test of time before tagging.
I am sure WMF developers are facing >similar issues especially
I don't think that's the case. It used to be the responsibility of the person making the breaking change to fix all callers in the wikimedia extension repo. Im not sure if that's still the case but nonetheless I do not feel this is a significant problem for deployed extensions.(im sure someone will correct me if im wrong)
-bawolff On 2013-02-11 9:14 AM, "Yuri Astrakhan" yuriastrakhan@gmail.com wrote:
Mariya,
Could you be more specific? What types of changes caused extensions to break? I might be mistaken but the vast majority of the API framework classes have been established over 5 years ago, with very few breaking changes since. Most changes were related to adding new functionality (new actions, new query submodules, new parameters), but that shouldn't have significantly affected extension development.
I do plan to introduce a few breaking changes (majority of the extensions should not be affected) in 1.21, such as the introduction of versioning, further modularization to allow pageset reuse, etc. See http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
Please note that in a rare case some features might be purposefully removed due to the security or scalability issues.
--Yuri
On Mon, Feb 11, 2013 at 7:58 AM, Mariya Nedelcheva Miteva < mariya.miteva@gmail.com> wrote:
Hi all,
I have been talking to many third-party yas part of my WMF internship in the last few weeks and one the main concerns they express is the lack of stability in the PHP classes MediaWiki exposes from version to version.
The
frequent changes in what I would call the PHP-API makes extentions developement and maintenance much more difficult with compatibility from version to version becoming a problem. Solving the problem would probably result in the development of more extensions, easier maintenance, less hacks to core and more users upgrading to the latest MediaWiki version. I am sure WMF developers are facing similar issues especially with projects like WikiData going on.
My question is: With the given technical heritage that MediaWiki carries, is it possible to have a (relatively) stable set of PHP classes defined, with a pledge not to change them in the next X releases or at least with some longer deprecation time? What would maintaining such a PHP-API
entail?
How difficult is it given the vast number of dependancies in MediaWiki code? Does it require restructuring a lot of the current core code? Do
you
think it should be a definite goal for WMF?
Thank you.
Mariya _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I have a blasphemous proposal... extensions should only use the public API via FauxRequest objects. The public API interface has been very stable, and it gives MW core devs much more flexibility with changing the innards of the system...
On Mon, Feb 11, 2013 at 8:36 AM, bawolff bawolff+wn@gmail.com wrote:
I don't think she means what we call the api - but more methods random extensions are likely to use.
We could start documenting certain stable methods with a special code comment ( say @stable) which would mean something like this method will not be removed, and if the need arises we'll remove the @stable and wait 2 versions before removing the method. Key candidates for this would include title::newFromText, parser::recursiveTagParse, etc. Ideally one would wait for the method to stand the test of time before tagging.
I am sure WMF developers are facing >similar issues especially
I don't think that's the case. It used to be the responsibility of the person making the breaking change to fix all callers in the wikimedia extension repo. Im not sure if that's still the case but nonetheless I do not feel this is a significant problem for deployed extensions.(im sure someone will correct me if im wrong)
-bawolff On 2013-02-11 9:14 AM, "Yuri Astrakhan" yuriastrakhan@gmail.com wrote:
Mariya,
Could you be more specific? What types of changes caused extensions to break? I might be mistaken but the vast majority of the API framework classes have been established over 5 years ago, with very few breaking changes since. Most changes were related to adding new functionality (new actions, new query submodules, new parameters), but that shouldn't have significantly affected extension development.
I do plan to introduce a few breaking changes (majority of the extensions should not be affected) in 1.21, such as the introduction of versioning, further modularization to allow pageset reuse, etc. See http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
Please note that in a rare case some features might be purposefully
removed
due to the security or scalability issues.
--Yuri
On Mon, Feb 11, 2013 at 7:58 AM, Mariya Nedelcheva Miteva < mariya.miteva@gmail.com> wrote:
Hi all,
I have been talking to many third-party yas part of my WMF internship
in
the last few weeks and one the main concerns they express is the lack
of
stability in the PHP classes MediaWiki exposes from version to version.
The
frequent changes in what I would call the PHP-API makes extentions developement and maintenance much more difficult with compatibility
from
version to version becoming a problem. Solving the problem would
probably
result in the development of more extensions, easier maintenance, less hacks to core and more users upgrading to the latest MediaWiki
version. I
am sure WMF developers are facing similar issues especially with
projects
like WikiData going on.
My question is: With the given technical heritage that MediaWiki
carries,
is it possible to have a (relatively) stable set of PHP classes
defined,
with a pledge not to change them in the next X releases or at least
with
some longer deprecation time? What would maintaining such a PHP-API
entail?
How difficult is it given the vast number of dependancies in MediaWiki code? Does it require restructuring a lot of the current core code? Do
you
think it should be a definite goal for WMF?
Thank you.
Mariya _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi Yuri,
As I haven't created an extension myself( which I realize is a huge problem when talking about this kind of a problem ), is this feasable for more complex extensiosns? If yes, why are people not doing it? Is is just because of lack of information?
Mariya
On Mon, Feb 11, 2013 at 3:47 PM, Yuri Astrakhan yuriastrakhan@gmail.comwrote:
I have a blasphemous proposal... extensions should only use the public API via FauxRequest objects. The public API interface has been very stable, and it gives MW core devs much more flexibility with changing the innards of the system...
On Mon, Feb 11, 2013 at 8:36 AM, bawolff bawolff+wn@gmail.com wrote:
I don't think she means what we call the api - but more methods random extensions are likely to use.
We could start documenting certain stable methods with a special code comment ( say @stable) which would mean something like this method will
not
be removed, and if the need arises we'll remove the @stable and wait 2 versions before removing the method. Key candidates for this would
include
title::newFromText, parser::recursiveTagParse, etc. Ideally one would
wait
for the method to stand the test of time before tagging.
I am sure WMF developers are facing >similar issues especially
I don't think that's the case. It used to be the responsibility of the person making the breaking change to fix all callers in the wikimedia extension repo. Im not sure if that's still the case but nonetheless I do not feel this is a significant problem for deployed extensions.(im sure someone will correct me if im wrong)
-bawolff On 2013-02-11 9:14 AM, "Yuri Astrakhan" yuriastrakhan@gmail.com wrote:
Mariya,
Could you be more specific? What types of changes caused extensions to break? I might be mistaken but the vast majority of the API framework classes have been established over 5 years ago, with very few breaking changes since. Most changes were related to adding new functionality
(new
actions, new query submodules, new parameters), but that shouldn't have significantly affected extension development.
I do plan to introduce a few breaking changes (majority of the
extensions
should not be affected) in 1.21, such as the introduction of
versioning,
further modularization to allow pageset reuse, etc. See http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
Please note that in a rare case some features might be purposefully
removed
due to the security or scalability issues.
--Yuri
On Mon, Feb 11, 2013 at 7:58 AM, Mariya Nedelcheva Miteva < mariya.miteva@gmail.com> wrote:
Hi all,
I have been talking to many third-party yas part of my WMF internship
in
the last few weeks and one the main concerns they express is the lack
of
stability in the PHP classes MediaWiki exposes from version to
version.
The
frequent changes in what I would call the PHP-API makes extentions developement and maintenance much more difficult with compatibility
from
version to version becoming a problem. Solving the problem would
probably
result in the development of more extensions, easier maintenance,
less
hacks to core and more users upgrading to the latest MediaWiki
version. I
am sure WMF developers are facing similar issues especially with
projects
like WikiData going on.
My question is: With the given technical heritage that MediaWiki
carries,
is it possible to have a (relatively) stable set of PHP classes
defined,
with a pledge not to change them in the next X releases or at least
with
some longer deprecation time? What would maintaining such a PHP-API
entail?
How difficult is it given the vast number of dependancies in
MediaWiki
code? Does it require restructuring a lot of the current core code?
Do
you
think it should be a definite goal for WMF?
Thank you.
Mariya _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I disagree with only. Extensions dont just query the db and sometimes extensions need to do things we cant put in a web api. But it would be *c*ool if using the api internally was encouraged.
(Keep in mind action=parse and action=edit of the api is unsafe to call internally at some points in the code)
-bawolff On 2013-02-11 9:47 AM, "Yuri Astrakhan" yuriastrakhan@gmail.com wrote:
I have a blasphemous proposal... extensions should only use the public API via FauxRequest objects. The public API interface has been very stable, and it gives MW core devs much more flexibility with changing the innards of the system...
On Mon, Feb 11, 2013 at 8:36 AM, bawolff bawolff+wn@gmail.com wrote:
I don't think she means what we call the api - but more methods random extensions are likely to use.
We could start documenting certain stable methods with a special code comment ( say @stable) which would mean something like this method will
not
be removed, and if the need arises we'll remove the @stable and wait 2 versions before removing the method. Key candidates for this would
include
title::newFromText, parser::recursiveTagParse, etc. Ideally one would
wait
for the method to stand the test of time before tagging.
I am sure WMF developers are facing >similar issues especially
I don't think that's the case. It used to be the responsibility of the person making the breaking change to fix all callers in the wikimedia extension repo. Im not sure if that's still the case but nonetheless I do not feel this is a significant problem for deployed extensions.(im sure someone will correct me if im wrong)
-bawolff On 2013-02-11 9:14 AM, "Yuri Astrakhan" yuriastrakhan@gmail.com wrote:
Mariya,
Could you be more specific? What types of changes caused extensions to break? I might be mistaken but the vast majority of the API framework classes have been established over 5 years ago, with very few breaking changes since. Most changes were related to adding new functionality
(new
actions, new query submodules, new parameters), but that shouldn't have significantly affected extension development.
I do plan to introduce a few breaking changes (majority of the
extensions
should not be affected) in 1.21, such as the introduction of
versioning,
further modularization to allow pageset reuse, etc. See http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
Please note that in a rare case some features might be purposefully
removed
due to the security or scalability issues.
--Yuri
On Mon, Feb 11, 2013 at 7:58 AM, Mariya Nedelcheva Miteva < mariya.miteva@gmail.com> wrote:
Hi all,
I have been talking to many third-party yas part of my WMF internship
in
the last few weeks and one the main concerns they express is the lack
of
stability in the PHP classes MediaWiki exposes from version to
version.
The
frequent changes in what I would call the PHP-API makes extentions developement and maintenance much more difficult with compatibility
from
version to version becoming a problem. Solving the problem would
probably
result in the development of more extensions, easier maintenance,
less
hacks to core and more users upgrading to the latest MediaWiki
version. I
am sure WMF developers are facing similar issues especially with
projects
like WikiData going on.
My question is: With the given technical heritage that MediaWiki
carries,
is it possible to have a (relatively) stable set of PHP classes
defined,
with a pledge not to change them in the next X releases or at least
with
some longer deprecation time? What would maintaining such a PHP-API
entail?
How difficult is it given the vast number of dependancies in
MediaWiki
code? Does it require restructuring a lot of the current core code?
Do
you
think it should be a definite goal for WMF?
Thank you.
Mariya _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I don't see how something like parser functions, wiki syntax extensions, skins, and many other extensions could feasibly be done using the Web-API.
2013/2/11 Yuri Astrakhan yuriastrakhan@gmail.com
I have a blasphemous proposal... extensions should only use the public API via FauxRequest objects. The public API interface has been very stable, and it gives MW core devs much more flexibility with changing the innards of the system...
On Mon, Feb 11, 2013 at 8:36 AM, bawolff bawolff+wn@gmail.com wrote:
I don't think she means what we call the api - but more methods random extensions are likely to use.
We could start documenting certain stable methods with a special code comment ( say @stable) which would mean something like this method will
not
be removed, and if the need arises we'll remove the @stable and wait 2 versions before removing the method. Key candidates for this would
include
title::newFromText, parser::recursiveTagParse, etc. Ideally one would
wait
for the method to stand the test of time before tagging.
I am sure WMF developers are facing >similar issues especially
I don't think that's the case. It used to be the responsibility of the person making the breaking change to fix all callers in the wikimedia extension repo. Im not sure if that's still the case but nonetheless I do not feel this is a significant problem for deployed extensions.(im sure someone will correct me if im wrong)
-bawolff On 2013-02-11 9:14 AM, "Yuri Astrakhan" yuriastrakhan@gmail.com wrote:
Mariya,
Could you be more specific? What types of changes caused extensions to break? I might be mistaken but the vast majority of the API framework classes have been established over 5 years ago, with very few breaking changes since. Most changes were related to adding new functionality
(new
actions, new query submodules, new parameters), but that shouldn't have significantly affected extension development.
I do plan to introduce a few breaking changes (majority of the
extensions
should not be affected) in 1.21, such as the introduction of
versioning,
further modularization to allow pageset reuse, etc. See http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
Please note that in a rare case some features might be purposefully
removed
due to the security or scalability issues.
--Yuri
On Mon, Feb 11, 2013 at 7:58 AM, Mariya Nedelcheva Miteva < mariya.miteva@gmail.com> wrote:
Hi all,
I have been talking to many third-party yas part of my WMF internship
in
the last few weeks and one the main concerns they express is the lack
of
stability in the PHP classes MediaWiki exposes from version to
version.
The
frequent changes in what I would call the PHP-API makes extentions developement and maintenance much more difficult with compatibility
from
version to version becoming a problem. Solving the problem would
probably
result in the development of more extensions, easier maintenance,
less
hacks to core and more users upgrading to the latest MediaWiki
version. I
am sure WMF developers are facing similar issues especially with
projects
like WikiData going on.
My question is: With the given technical heritage that MediaWiki
carries,
is it possible to have a (relatively) stable set of PHP classes
defined,
with a pledge not to change them in the next X releases or at least
with
some longer deprecation time? What would maintaining such a PHP-API
entail?
How difficult is it given the vast number of dependancies in
MediaWiki
code? Does it require restructuring a lot of the current core code?
Do
you
think it should be a definite goal for WMF?
Thank you.
Mariya _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hi all,
For what I've undrstood from conversations so far the Web or HTML API is not enough for extension developement and the variability of exposed internal classes is often responsible for the incompatibility of extensions with certain MediaWiki versions. Correct me if I am wrong.
We could start documenting certain stable methods with a special code comment ( say @stable) which would mean something like this method will
not
be removed, and if the need arises we'll remove the @stable and wait 2 versions before removing the method. Key candidates for this would
include
title::newFromText, parser::recursiveTagParse, etc. Ideally one would
wait
for the method to stand the test of time before tagging.
So would this be a feasable improvement? Are there any other ideas of what can be done?
I will hopefully sent an email with more specific examples tomorrow. Also, would it be useful to have some sort of a IRC chat or other form of conversation about this ?
Mariya
On Mon, Feb 11, 2013 at 5:21 PM, Denny Vrandečić < denny.vrandecic@wikimedia.de> wrote:
I don't see how something like parser functions, wiki syntax extensions, skins, and many other extensions could feasibly be done using the Web-API.
2013/2/11 Yuri Astrakhan yuriastrakhan@gmail.com
I have a blasphemous proposal... extensions should only use the public
API
via FauxRequest objects. The public API interface has been very stable,
and
it gives MW core devs much more flexibility with changing the innards of the system...
On Mon, Feb 11, 2013 at 8:36 AM, bawolff bawolff+wn@gmail.com wrote:
I don't think she means what we call the api - but more methods random extensions are likely to use.
We could start documenting certain stable methods with a special code comment ( say @stable) which would mean something like this method will
not
be removed, and if the need arises we'll remove the @stable and wait 2 versions before removing the method. Key candidates for this would
include
title::newFromText, parser::recursiveTagParse, etc. Ideally one would
wait
for the method to stand the test of time before tagging.
I am sure WMF developers are facing >similar issues especially
I don't think that's the case. It used to be the responsibility of the person making the breaking change to fix all callers in the wikimedia extension repo. Im not sure if that's still the case but nonetheless I
do
not feel this is a significant problem for deployed extensions.(im sure someone will correct me if im wrong)
-bawolff On 2013-02-11 9:14 AM, "Yuri Astrakhan" yuriastrakhan@gmail.com
wrote:
Mariya,
Could you be more specific? What types of changes caused extensions
to
break? I might be mistaken but the vast majority of the API framework classes have been established over 5 years ago, with very few
breaking
changes since. Most changes were related to adding new functionality
(new
actions, new query submodules, new parameters), but that shouldn't
have
significantly affected extension development.
I do plan to introduce a few breaking changes (majority of the
extensions
should not be affected) in 1.21, such as the introduction of
versioning,
further modularization to allow pageset reuse, etc. See http://www.mediawiki.org/wiki/Requests_for_comment/API_Future
Please note that in a rare case some features might be purposefully
removed
due to the security or scalability issues.
--Yuri
On Mon, Feb 11, 2013 at 7:58 AM, Mariya Nedelcheva Miteva < mariya.miteva@gmail.com> wrote:
Hi all,
I have been talking to many third-party yas part of my WMF
internship
in
the last few weeks and one the main concerns they express is the
lack
of
stability in the PHP classes MediaWiki exposes from version to
version.
The
frequent changes in what I would call the PHP-API makes extentions developement and maintenance much more difficult with compatibility
from
version to version becoming a problem. Solving the problem would
probably
result in the development of more extensions, easier maintenance,
less
hacks to core and more users upgrading to the latest MediaWiki
version. I
am sure WMF developers are facing similar issues especially with
projects
like WikiData going on.
My question is: With the given technical heritage that MediaWiki
carries,
is it possible to have a (relatively) stable set of PHP classes
defined,
with a pledge not to change them in the next X releases or at least
with
some longer deprecation time? What would maintaining such a PHP-API
entail?
How difficult is it given the vast number of dependancies in
MediaWiki
code? Does it require restructuring a lot of the current core code?
Do
you
think it should be a definite goal for WMF?
Thank you.
Mariya _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 11.02.2013 20:19, Mariya Nedelcheva Miteva wrote:
Hi all,
For what I've undrstood from conversations so far the Web or HTML API is not enough for extension developement and the variability of exposed internal classes is often responsible for the incompatibility of extensions with certain MediaWiki versions. Correct me if I am wrong.
Stable internal API means MediaWiki LTS version. Another alternative is to update extensions to keep them compatible to internal API changes / new features. There were quite a lot of outdated and abandoned extensions at mediawiki.org Sometimes they are abandoned because the author lost his interest in developing for MediaWiki. But there are another cases when customer funding was small / short, very limited and thus extension's maintainer does not have enough time to support it. WMF extensions are updated, that's true, however there are many more extensions used at 3rd party wikis. Not so top quality as major WMF extensions, though. If there were corporate donations for non-WMF extensions, things could have been improved. But usually 3rd party site owners want quality for free while not willing to provide funding for long-time support. That's life. Developing free software is great, until living difficulties come. Dmitriy
Hello Mariya,
I'm not a WMF developer, but in my opinion, MediaWiki is already a fairly stable product. I personally had no problems with any PHP API changes :-) and I think it would be good if you provide some examples - what changes were a problem for someone?
vitalif@yourcmc.ru writes:
I think it would be good if you provide some examples - what changes were a problem for someone?
See extensive examples in my post about 1.18 update difficulties: http://lists.wikimedia.org/pipermail/wikitech-l/2012-January/057486.html
DanB
Le 11/02/13 13:58, Mariya Nedelcheva Miteva a écrit :
I have been talking to many third-party yas part of my WMF internship in the last few weeks and one the main concerns they express is the lack of stability in the PHP classes MediaWiki exposes from version to version.
<snip>
That has been kind of a recurring issue over the last few years. VistaPrint have some nice and smart people, some of them are subscribed to our lists. Back in January 2012, "danb" posted a long email regarding the upgrade of their internal installation from 1.18 to 1.19. Do read it:
http://www.gossamer-threads.com/lists/wiki/wikitech/267106
He list 9 examples of breakages VistaPrint encountered in MediaWiki extensions:
1) removal of global $action 2) removal of Xml::hidden() 3) broken Output::add() (had to migrate to resource loader) 4) various parser tag bugs 5) removal of MessageCache::addMessage() 6) removal of ts_makeSortable() (javascript) 7) brokage of WikiEditor adaptation 8) MediaWiki:common.js no more loading by default (security) 9) addHandler() javascript broken in IE8
Then the awesome Rob Lanphier (disclaimer: he is the director signing my contracts within the WMF) replied about us "breaking backwards compatibility" at http://www.gossamer-threads.com/lists/wiki/wikitech/267180
Since then, Rob has constantly stressed the MediaWiki core team to retain backward compatibility as much as possible. I think nowadays we most of the time leave behind a back compatibility call flagged with wfDeprecated() and remove the function after a few releases. I guess that would prevent lot of breakage in the future.
The JavaScript issues are probably related to us not having the nice JS we have today nor the awesome QUnit test suite Krinkle bootstraped. I guess some of those issues would be catched nowadays.
Same for IE8 compatibility, we have some virtual machines running Selenium tests against tons and tons of different browser. That raises our likeness to detect such issues.
Anyway, what we could do is start writing PHP interfaces for our legacy code and have our classes defined as implementing them:
http://php.net/manual/en/language.oop5.interfaces.php
That would force us to actually document all of our legacy code and will present a nice list of what we expose to the public.
cheers,
- removal of global $action
- removal of Xml::hidden()
- broken Output::add() (had to migrate to resource loader)
- various parser tag bugs
- removal of MessageCache::addMessage()
- removal of ts_makeSortable() (javascript)
- brokage of WikiEditor adaptation
- MediaWiki:common.js no more loading by default (security)
- addHandler() javascript broken in IE8
Most of these were deprecations, am I correct?
Le 11/02/13 19:58, vitalif@yourcmc.ru a écrit :
- removal of global $action
- removal of Xml::hidden()
- broken Output::add() (had to migrate to resource loader)
- various parser tag bugs
- removal of MessageCache::addMessage()
- removal of ts_makeSortable() (javascript)
- brokage of WikiEditor adaptation
- MediaWiki:common.js no more loading by default (security)
- addHandler() javascript broken in IE8
Most of these were deprecations, am I correct?
I guess so. Probably methods we simply removed instead of deprecating them like we are doing nowadays.
Hi everyone,
I guess it is a little difficult for me to describe what I mean since I am just rephrasing what I've heard from others. I am still waiting for some more specific examples. However, I think most people are facing the kind of problems which Daniel has so well described in his post to the mailing list.
Maybe this quotation will help clarify things.
Mostly I want core developers to think about MediaWiki as framework with programming interfaces for extension developers. All the changes in those interfaces have to be calm, with slow deprecation. A role model for that is Python compiler. ( http://www.mediawiki.org/wiki/Talk:Third-party_MediaWiki_users_discussion#Fe... )
I understand from your comments that keeping things stable and preserving compatibiliy HAS been a priority for core developers at least since Daniel's email. Is this really the case? If this is the case, it makes me wonder why I hear some complaints about it. Is it maybe that documentation is not clear on what will be stable and can be used and what should not be used? Or is it a matter of educating extension developers how to find such information?
On a brighter note, I heard that the LTS version 1.19 was the best thing that happened since sliced bread :)
Mariya
On Tue, Feb 12, 2013 at 10:03 AM, Antoine Musso hashar+wmf@free.fr wrote:
Le 11/02/13 19:58, vitalif@yourcmc.ru a écrit :
- removal of global $action
- removal of Xml::hidden()
- broken Output::add() (had to migrate to resource loader)
- various parser tag bugs
- removal of MessageCache::addMessage()
- removal of ts_makeSortable() (javascript)
- brokage of WikiEditor adaptation
- MediaWiki:common.js no more loading by default (security)
- addHandler() javascript broken in IE8
Most of these were deprecations, am I correct?
I guess so. Probably methods we simply removed instead of deprecating them like we are doing nowadays.
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
By the way, Daniel, have you had similar problems with your next upgrades? Maybe things have indeed improved since your post about 1.18
Mariya
On Tue, Feb 12, 2013 at 3:14 PM, Maria Miteva mariya.miteva@gmail.comwrote:
Hi everyone,
I guess it is a little difficult for me to describe what I mean since I am just rephrasing what I've heard from others. I am still waiting for some more specific examples. However, I think most people are facing the kind of problems which Daniel has so well described in his post to the mailing list.
Maybe this quotation will help clarify things.
Mostly I want core developers to think about MediaWiki as framework with programming interfaces for extension developers. All the changes in those interfaces have to be calm, with slow deprecation. A role model for that is Python compiler. ( http://www.mediawiki.org/wiki/Talk:Third-party_MediaWiki_users_discussion#Fe... )
I understand from your comments that keeping things stable and preserving compatibiliy HAS been a priority for core developers at least since Daniel's email. Is this really the case? If this is the case, it makes me wonder why I hear some complaints about it. Is it maybe that documentation is not clear on what will be stable and can be used and what should not be used? Or is it a matter of educating extension developers how to find such information?
On a brighter note, I heard that the LTS version 1.19 was the best thing that happened since sliced bread :)
Mariya
On Tue, Feb 12, 2013 at 10:03 AM, Antoine Musso hashar+wmf@free.frwrote:
Le 11/02/13 19:58, vitalif@yourcmc.ru a écrit :
- removal of global $action
- removal of Xml::hidden()
- broken Output::add() (had to migrate to resource loader)
- various parser tag bugs
- removal of MessageCache::addMessage()
- removal of ts_makeSortable() (javascript)
- brokage of WikiEditor adaptation
- MediaWiki:common.js no more loading by default (security)
- addHandler() javascript broken in IE8
Most of these were deprecations, am I correct?
I guess so. Probably methods we simply removed instead of deprecating them like we are doing nowadays.
-- Antoine "hashar" Musso
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
We had quite a bit of difficulty moving from 1.18 to 1.20 because of mysterious JavaScript timing issues in WikiEditor. http://www.mediawiki.org/wiki/Talk:MediaWiki_vendors#WikiEditor_toolbars.2C_...
On the PHP side, some protected variables in a class (I think UserMailer) got changed to private, which broke some extensions that subclassed it. That kind of change should be strongly discouraged, or accompanied by some new functions that access the now-private member.
DanB
From: mnm301@nyu.edu [mailto:mnm301@nyu.edu] On Behalf Of Mariya Nedelcheva Miteva Sent: Tuesday, February 12, 2013 9:23 AM To: Daniel Barrett; Wikimedia developers Subject: Re: [Wikitech-l] Stable PHP API for MediaWiki ?
By the way, Daniel, have you had similar problems with your next upgrades? Maybe things have indeed improved since your post about 1.18
Mariya On Tue, Feb 12, 2013 at 3:14 PM, Maria Miteva <mariya.miteva@gmail.commailto:mariya.miteva@gmail.com> wrote: Hi everyone,
I guess it is a little difficult for me to describe what I mean since I am just rephrasing what I've heard from others. I am still waiting for some more specific examples. However, I think most people are facing the kind of problems which Daniel has so well described in his post to the mailing list.
Maybe this quotation will help clarify things.
Mostly I want core developers to think about MediaWiki as framework with programming interfaces for extension developers. All the changes in those interfaces have to be calm, with slow deprecation. A role model for that is Python compiler. ( http://www.mediawiki.org/wiki/Talk:Third-party_MediaWiki_users_discussion#Fe... )
I understand from your comments that keeping things stable and preserving compatibiliy HAS been a priority for core developers at least since Daniel's email. Is this really the case? If this is the case, it makes me wonder why I hear some complaints about it. Is it maybe that documentation is not clear on what will be stable and can be used and what should not be used? Or is it a matter of educating extension developers how to find such information?
On a brighter note, I heard that the LTS version 1.19 was the best thing that happened since sliced bread :)
Mariya
On Tue, Feb 12, 2013 at 10:03 AM, Antoine Musso <hashar+wmf@free.frmailto:hashar+wmf@free.fr> wrote: Le 11/02/13 19:58, vitalif@yourcmc.rumailto:vitalif@yourcmc.ru a écrit :
- removal of global $action
- removal of Xml::hidden()
- broken Output::add() (had to migrate to resource loader)
- various parser tag bugs
- removal of MessageCache::addMessage()
- removal of ts_makeSortable() (javascript)
- brokage of WikiEditor adaptation
- MediaWiki:common.js no more loading by default (security)
- addHandler() javascript broken in IE8
Most of these were deprecations, am I correct?
I guess so. Probably methods we simply removed instead of deprecating them like we are doing nowadays.
-- Antoine "hashar" Musso
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.orgmailto:Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I understand from your comments that keeping things stable and preserving compatibiliy HAS been a priority for core developers at least since Daniel's email. Is this really the case? If this is the case, it makes me wonder why I hear some complaints about it.
Mariya, but did you hear that many complaints? :-)
On 02/12/2013 08:14 AM, Maria Miteva wrote:
On a brighter note, I heard that the LTS version 1.19 was the best thing that happened since sliced bread :)
This makes me very happy.
I'm going to start paying close attention to people who have problems upgrading from 1.19 over the next couple of years so that when we hit the next LTS (1.25) in 2015, we'll have fewer issues for the people moving from 1.19 to 1.25.
I would like to ask your help with this, of course. If you see something that you think we should take note of and fix, let me know.
A big part of this is going to be those non-WMF extensions that people like to use. I'm not too worried about the popular SMW extensions -- the SMW folks have a good handle on the LTS -- but if you install an extension with the expectation that it will be maintained for LTS releases, you need to make sure that it is going to be supported.
I'd like to think that extensions in [[Category:Stable_extensions]] will be maintained, but maybe that isn't right. I certainly haven't tried all of them against 1.19.
Developers can help out with this. On Debian, for example, developers can announce that they're orphaning a package and it needs a new maintainer. Ideally, a developer would find someone to maintain his own extension, but if you see an orphaned extension or just don't feel like maintaining one any more, please add {{Unmaintained extension}} to its page on MediaWiki.org.
That said, I've created a category page on MediaWiki.org -- https://www.mediawiki.org/wiki/Category:Not_LTS_ready -- for extensions are marked Stable but unmaintained.
(I still have to actually put pages in the category, but I'll do that after dinner.)
Mark.
On 12 February 2013 23:48, Mark A. Hershberger mah@everybody.org wrote:
I'm going to start paying close attention to people who have problems upgrading from 1.19 over the next couple of years so that when we hit the next LTS (1.25) in 2015, we'll have fewer issues for the people moving from 1.19 to 1.25.
Waiting that long? That'll leave Ubuntu 14.04 with 1.19 unsupportable for a year or so. It also strikes me as a long time given the pace of MW development. (I suppose I'd be asking a lot to ask for overlapping LTS times.)
The rest of your post is wonderful and heartwarming stuff for a tarball user to hear :-)
- d.
On 13 February 2013 01:48, Mark A. Hershberger mah@everybody.org wrote:
I'm going to start paying close attention to people who have problems upgrading from 1.19 over the next couple of years so that when we hit the next LTS (1.25) in 2015, we'll have fewer issues for the people moving from 1.19 to 1.25.
There is near zero chance that I will keep supporting 1.19 for that long in master branch in all of my extensions (and this is assuming support for 1.19 is dropped immediately when 1.25 is released). It's already hard since 1.19 is missing some features I need.
People need to realize that they can't get the latest shiny extensions on years old MediaWiki. For extensions this would mean that they would create a branch with security fixes and other important bug fixes for 1.19. MLEB will probably just declare some release as the last release that works with 1.19.
1.19 was released on 2012-02-09. For comparison Ubuntu has released LTS version every two years.
I'd like to think that extensions in [[Category:Stable_extensions]] will be maintained, but maybe that isn't right. I certainly haven't tried all of them against 1.19.
Maintained doesn't necessarily mean support for 1.19 is kept.
Developers can help out with this. On Debian, for example, developers can announce that they're orphaning a package and it needs a new maintainer. Ideally, a developer would find someone to maintain his own extension, but if you see an orphaned extension or just don't feel like maintaining one any more, please add {{Unmaintained extension}} to its page on MediaWiki.org.
Has any extension been adopted this way?
-Niklas
-- Niklas Laxström
Niklas voiced what will surely be a common refrain amongst extension developers:
On 02/13/2013 02:09 AM, Niklas Laxström wrote:
There is near zero chance that I will keep supporting 1.19 for that long in master branch in all of my extensions (and this is assuming support for 1.19 is dropped immediately when 1.25 is released). It's already hard since 1.19 is missing some features I need.
People need to realize that they can't get the latest shiny extensions on years old MediaWiki. For extensions this would mean that they would create a branch with security fixes and other important bug fixes for 1.19. MLEB will probably just declare some release as the last release that works with 1.19.
As we develop our LTS policy (and it has to be a policy developed by all of us so that there is some consensus about it), we need to flesh these things out.
I didn't intend to equate maintenance with LTS support with implementation of all the latest features of an extension, but the way I framed it -- and the change I made to Niklas APC extension release status MW.o -- made it look that way.
As Niklas says:
Maintained doesn't necessarily mean support for 1.19 is kept.
True.
We can satisfy LTS users (who want to know that X extension will work with their version of MW) and developers (who don't want to spend too much time maintaining their extensions for old MW) by updating the "Release Status" box and adding a link to a version of the extension that has been verified to work with the LTS.
As for finding maintainers for orphaned extensions: that is something we haven't tried yet. I hope it we can find them in cases where we need them. Nemo pointed me to http://wikiapiary.com/wiki/Extension:Apc for sites that use the APC extension -- which Niklas has said needs a new maintainer.
On Tue, 2013-02-12 at 18:48 -0500, Mark A. Hershberger wrote:
I'd like to think that extensions in [[Category:Stable_extensions]] will be maintained, but maybe that isn't right. I certainly haven't tried all of them against 1.19.
Wondering how differently "Stable extensions" is interpreted by individuals who once upon a time added that category on an extension homepage and then forgot about it...</pessimism>
andre
- removal of global $action
- removal of Xml::hidden()
- broken Output::add() (had to migrate to resource loader)
- various parser tag bugs
- removal of MessageCache::addMessage()
- removal of ts_makeSortable() (javascript)
- brokage of WikiEditor adaptation
- MediaWiki:common.js no more loading by default (security)
- addHandler() javascript broken in IE8
Documentation seems partially the answer here. $action being available at any point was an accident afaik. Regardless of any precaitions we take, the breakage of $action would probably not be ptevented. (That said most of the other issues mentioned should not have happened).
wikitech-l@lists.wikimedia.org