Last modified: 2012-09-24 16:46:51 UTC
The Wikipedia Foundation uses the Wikipedia-content-model (fast development, mass-review) also for continuous software integration for the mediawiki version running the Wikipedias. It used to be possible for other sites to benefit from this. Starting with mediawiki 1.16, this was given up and the continuous integration separated into the wmf branches. Since then the choice seems to be a highly unstable development only version or traditional yearly volumes of "stable" but completely out of date releases. Testing of the current 1.17wmf shows that this version contains is indeed very hard to re-use and after several bug reports I was advised not to use the wmf software. The alternative 1.17, released in June 2011, lacks much functionality that is already well known from Wikipedias: No WikiLove, no working ArticleFeedback or UploadWizard (the 1.17 "stable" version of the upload wizards says "This extension is currently experimental and almost certainly won't work for you (yet). We anticipate having a working version in late October / early November 2010"). Many more current Wikipedia feature are highly dated in the stable version. All these features are available in the 1.17wmf, but this version is built so it works only on wmf servers (e.g., the database updates in maintenance are disabled). I submit this bug in the hope of initiating a thought process, whether this has to be so. I understand all of lack of time, resource constraints, ...
We're already working on making this happen. The large distance between 1.17 and trunk means merges to 1.17wmf1 are painful, and we feel that pain every day. So we want more frequent deployments and deploy things that are closer to trunk, if not trunk itself. We're currently almost done doing code review for 1.18, so we should be able to deploy that to a test wiki soon. After that we're planning to make the cycle shorter.
Hi Gregor, I'd like to second Roan's comment, and also possibly clarify. The one area we're currently focused on is reducing the time between major deployments (e.g. the time between 1.17wmf1->1.18wmf1). The frustration you seem to have is the delta between the WMF version and what we ultimately release. For practical purposes, our reduction in the time between deployments will help a lot, but isn't focused on that problem. If you're eager to run with WikiLove and ArticleFeedback, you may want to try checking out the REL1_18 branch now. There's a pretty good chance that any problems that you find will be quickly addressed by the development team, since we're focused on getting those features deployed, and can use the testing help.
Thanks Roan and Rob. I appreciate the advice, and can confim that 1.18alpha is working relatively well and is relatively modern. In general I still believe the development process could be coupled closer with software user (again, like it had been before 1.16) with the actual Wikipedia version. My fuzzy idea is that a full, usable, generic code version should be available to all, to allow running the same version as Wikipedia, covering and disseminating all the effort that goes into "backporting" from trunk. Only in a second branch based on the first, the Wikipedia-specific changes (like disabling/rewriting maintenance scripts, removing essential parts of code like geshi from svn, etc.) would be made. Contributing bug reports on an almost-stable 1.18 is possible, but after the release of 1.18 this will cease again, our svn updating will be caught in 1.18, while WMF will continue to backport newer developments. Bug reports then will be limited to those that a few developers experience themselves.
(In reply to comment #3) > Thanks Roan and Rob. I appreciate the advice, and can confim that 1.18alpha is > working relatively well and is relatively modern. > > In general I still believe the development process could be coupled closer with > software user (again, like it had been before 1.16) with the actual Wikipedia > version. We also want that to happen. The reason things slipped after 1.16 was primarily because were understaffed and busy. We intend to get close to trunk again, but we have some catching up to do before we get there.
Note that 1.18alpha is more "modern" than 1.17wmf1. 1.17wmf1 is a copy of REL1_17 + merges of some functions and patches that are needed.
New insight into the "mediawiki stability and release cycle problem" from a user perspective: The problem may be that the "stable" attribute of mediawiki releases may refer only to the core, not to the extensions that come with it. Before releasing 1.18: do you plan to backport all the bugs in extensions found since then? I checked code changes/review, and could find no backports of bug corrections in extensions to the "stable" releases, neither 1.17 nor 1.18. However, 1.17wmf is regularly fixed, both for mw core AND those extensions used on wmf. See also Bug 30565 as example. SMW in 1.18 is a release candidate 1.6, since then fixed to 1.6.2. However, no backporting activity occurs.
It seems some extensions purposely do not want / can participate in the stable releases (see discussions on bug 30565). In my opinion, it would be more transparent and easier, if those extensions (like the SMW-ones that require to be individually checked out through their release tag scheme) would be removed from the Mediawiki stable releases starting with REL1_18. Presently the MW releases suggest that they would be stable (or bugfixed) as well, but this is not occurring. Removing them from REL1_18 SVN would make this transparent and simpler to fill the gap by separate checkouts.
Here is my work for those intending to use 1.18, replacing the buggy extensions, at least the SMW of which will not be made stable, with the most recent stable releases. At the moment each user of mediawiki/SWM has to figure out the following combination: svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/AdminLinks/REL_0_1_4 AdminLinks svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/ExternalData/REL_1_3_1 ExternalData svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/HeaderTabs/REL_0_8_3 HeaderTabs svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/Maps/REL_1_0_2 Maps svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/OpenID/REL_0_9 OpenID svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/PageObjectModel/REL_0_1_3 PageObjectModel svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/ReplaceText/REL_0_9_1 ReplaceText svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/SemanticCalendar/REL_0_2_9 SemanticCalendar svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/SemanticCompoundQueries/REL_0_2_9 SemanticCompoundQueries svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/SemanticDrilldown/REL_0_8_3 SemanticDrilldown svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/SemanticForms/REL_2_2_1 SemanticForms svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/SemanticFormsInputs/REL_0_4_1 SemanticFormsInputs svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/SemanticInternalObjects/REL_0_6_6 SemanticInternalObjects svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/SemanticMaps/REL_1_0_2 SemanticMaps svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/SemanticMediaWiki/REL_1_6 SemanticMediaWiki svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/SemanticResultFormats/REL_1_6_1 SemanticResultFormats svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/SocialProfile/REL_1_3 SocialProfile svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/Validator/REL_0_4_9 Validator svn checkout http://svn.wikimedia.org/svnroot/mediawiki/tags/extensions/Widgets/REL_0_9_2 Widgets I personally would prefer if these extensions would be updated in the REL1_18 branch centrally by the release manager. REL1_18 would then come with more stable extensions. Perhaps the list, containing the most recent release tags, can help with this.
I appreciate the much closer cycle now achieved with 1.20, many thanks to all who have worked hard towards this. This essentially closes this "feature request".
