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(a)gmail.com> wrote:

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(a)gmail.com> wrote: (new have extensions versioning, internship in lack of version. from less version. defined, with MediaWiki Do

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 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(a)gmail.com> wrote:

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(a)gmail.com>wrote;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(a)gmail.com> -- 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.

On 11.02.2013 20:19, Mariya Nedelcheva Miteva wrote: 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

vitalif(a)yourcmc.ru writes: See extensive examples in my post about 1.18 update difficulties: http://lists.wikimedia.org/pipermail/wikitech-l/2012-January/057486.html DanB

Most of these were deprecations, am I correct?

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#F… ) 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(a)free.fr> wrote:

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(a)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.com<mailto: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#F… ) 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<mailto:hashar+wmf@free.fr>> wrote: Le 11/02/13 19:58, vitalif@yourcmc.ru<mailto:vitalif@yourcmc.ru> a écrit : 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<mailto:Wikitech-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

On 02/12/2013 08:14 AM, Maria Miteva wrote: 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 13 February 2013 01:48, Mark A. Hershberger &lt;mah(a)everybody.org&gt; 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. 1.19 was released on 2012-02-09. For comparison Ubuntu has released LTS version every two years. Maintained doesn't necessarily mean support for 1.19 is kept. Has any extension been adopted this way? -Niklas -- Niklas Laxström

On Tue, 2013-02-12 at 18:48 -0500, Mark A. Hershberger wrote: 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 -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/