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