On Tue, Sep 6, 2011 at 2:05 PM, Brion Vibber br...@pobox.com wrote:
Generally speaking, we should only throw warnings or remove old interfaces
that are actively broken (do not work correctly) or can no longer be sanely
maintained -- removing a deprecated interface is a fairly extreme step and
...@wikimedia.org
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Sent: Wed, Sep 7, 2011 06:23:45 GMT+00:00
Subject: Re: [Wikitech-l] Can we make the life of extension developers easier?
On Tue, Sep 6, 2011 at 2:05 PM, Brion Vibber br...@pobox.com wrote:
Generally speaking, we should only throw
On Wed, Sep 7, 2011 at 3:39 PM, Sumana Harihareswara
suma...@wikimedia.org wrote:
On 9/7/11, Russell N. Nelson - rnnelson rnnel...@clarkson.edu wrote:
Thank you for contributing emptiness?
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
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
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
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
There seem to be two groups of extensions: those which are not really
maintained, and those with active maintenance and development work. We
are relatively strict keeping our new core code backwards compatible
(BC). That compatibility does not come free, but who is it for? It is
for people who are
On Fri, Sep 2, 2011 at 4:40 PM, Niklas Laxström
niklas.laxst...@gmail.com wrote:
2) encourage adding FC interfaces to previous branches where possible
(and to also make releases out of those branches including the
interfaces)
By forward compat do you mean stuff like
Hey,
1) start enforcing @since annotations for new core code
This would help so much :) I requested this about half a year back and got a
bunch of sarcasm back then. Quite often I find out that I released some
version of some extension that's not compatible with an older version of
MediaWiki
Niklas Laxström niklas.laxst...@gmail.com wrote in message
news:CAAVd=jbYKaqR83tbwHAOiFiqrb_wcF70Jk=zdlqtwfiumjn...@mail.gmail.com...
I would like for us to:
1) start enforcing @since annotations for new core code
2) encourage adding FC interfaces to previous branches where possible
(and to
Am 02.09.2011 16:40, schrieb Niklas Laxström:
... The current practice seems to be:
1) keep the old interface available unless it makes no sense anymore
2) add @deprecated in X, warnings in X+2, removed in X+4 where X is
the current development version, the numbers may wary a little
Niklas,
On Sat, Sep 3, 2011 at 12:40 AM, Niklas Laxström
niklas.laxst...@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
12 matches
Mail list logo
