This is essentially why I've always preferred trunk extensions to be written to be compatible with at least latest stable. Most extension developers don't test and backport their changes to REL#_## branches so I've always installed trunk versions of extensions into my stable installations of MediaWiki. Frankly I don't consider /trunk/extensions to be the same as /trunk/phase3. To me /branches/REL#_##/phase3 has always been stable, /trunk/phase3 unstable in-development, /trunk/extensions the latest usable version of an extension, while /branches/REL#_##/extensions is a last-resort backup if the trunk version of an extension isn't functioning, or you're using and old version of MediaWiki.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On 11-09-07 05:44 PM, Christopher Wilson wrote:
Putting my sysadmin hat on, I would prefer that extensions be coded against the current stable release. I realize that there's a great temptation to code ahead and use new features/interfaces, but I almost always encounter pushback when the only way to do something is to use a beta version. Lots of outside organizations are going to be unwilling (or unable due to corporate policies) to run a trunk version of MW.
-Chris
On Wed, Sep 7, 2011 at 5:27 PM, Ian Baker ian@wikimedia.org wrote:
Along these lines, does it make sense to develop extensions against the last release when possible (that is, avoid new interfaces until they're actually available)? Extensions are coded a lot faster than core, and are released more often, but our default behavior seems to be to code against trunk, which can be months ahead of whatever is considered stable.
I know we plan to change this, and deploy trunk as often as every week, but even then our packaged releases (ie. the core code used everywhere outside the WMF) could be months old.
-Ian
On Fri, Sep 2, 2011 at 4:47 PM, K. Peachey p858snake@gmail.com wrote:
On Sat, Sep 3, 2011 at 12:40 AM, Niklas Laxström niklas.laxstrom@gmail.com wrote:
We are relatively strict keeping our new core code backwards compatible (BC). That compatibility does not come free, but who is it for?
Well it sort of does come free, just most people don't seem to use it.
We already have "/tags/RELX_YY_Z/extensions" (and "/tags/extensions" if they don't follow release numbering schemes (Example here are the Semantic* exts)) as well as "/branches/RELX_YY/extensions" where developers can keep extensions in a state to support BC with that version whilst integrating new features, One example of a dev doing this is the one working on the Favourites extension.
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