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 MediaW
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
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,
On Wed, Sep 7, 2011 at 3:39 PM, Sumana Harihareswara
wrote:
> On 9/7/11, Russell N. Nelson - rnnelson wrote:
Thank you for contributing emptiness?
Roan Kattouw (Catrope)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wiki
rizon Wireless Phone
>
>
> -Original message-
> From: Rob Lanphier
> To: Wikimedia developers
> 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, Bri
r
To: Wikimedia developers
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 wrote:
> Generally speaking, we should only throw warnings or remove old interfaces
> that are acti
On Tue, Sep 6, 2011 at 2:05 PM, Brion Vibber 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
> should never
On Fri, Sep 2, 2011 at 7:40 AM, Niklas Laxström
wrote:
> Having said that, I think BC is important and we should continue be as
> strict about it as we have been. The current practice seems to be:
> 1) keep the old interface available unless it makes no sense anymore
> 2) add @deprecated in X, war
On Sat, Sep 3, 2011 at 12:40 AM, Niklas Laxström
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/REL
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,
"Niklas Laxström" 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 also make releases o
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 it
On Fri, Sep 2, 2011 at 4:40 PM, Niklas Laxström
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
https://secure.wikimedia.org/wikipedia/mediawiki/
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
14 matches
Mail list logo
