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 <[email protected]> wrote: > On Sat, Sep 3, 2011 at 12:40 AM, Niklas Laxström > <[email protected]> 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
