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 <yuriastrak...@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...@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" <yuriastrak...@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.mit...@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 > _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
