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