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(a)gmail.com> wrote:
On Sat, Sep 3, 2011 at 12:40 AM, Niklas Laxström
<niklas.laxstrom(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l