Hey,
I'm wondering about two things:
* When will we finally drop 5.2.x support? * Can we have isolated components in core that require 5.3?
It's been one and a half years since the PHP guys dropped support for 5.2.x. What's still keeping us from doing so? Would dropping it in 1.20 work? That'll likely be in more then half a year from now, so over 2 years since PHP dropped support, which seems to be a very reasonable compatibility timespan (esp if you consider 5.3 will have been available for 3 years at that point). Personally I have not noticed the need for 5.2.x support in a while. 4 of my 6 last extensions require 5.3, and I only had a single person complain to me about this (which was over half a year ago IIRC). So it seems to me that people upgrading their wiki software have 5.3 already or have no problem with upgrading it.
My second question is about isolated utilities in core. With isolated I mean that although they might be using core, core does not use them. Can we at this point introduce such utilities that require 5.3, assuming there is good reason to have these utilities and that they cannot be made to work (sanely) with 5.2.x?
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On 12 February 2012 13:34, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey,
My second question is about isolated utilities in core. With isolated I mean that although they might be using core, core does not use them. Can we at this point introduce such utilities that require 5.3, assuming there is good reason to have these utilities and that they cannot be made to work (sanely) with 5.2.x?
Eg?
--HM
Hey,
On 12 February 2012 15:52, Happy Melon happy.melon.wiki@gmail.com wrote: Eg?
https://www.mediawiki.org/wiki/User:Jeroen_De_Dauw/DBDataObject
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On 12 February 2012 15:29, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey,
On 12 February 2012 15:52, Happy Melon happy.melon.wiki@gmail.com
wrote:
Eg?
https://www.mediawiki.org/wiki/User:Jeroen_De_Dauw/DBDataObject
I had just twigged myself that that was what you were refering to. That's not really a good example of an "isolated" utility; I would interpret such a thing to be something that core genuinely doesn't *need*, not just something it doesn't *currently* use. Although retro-engineering that framework into our core data classes would be an absolute bitch, if we were rewriting MW from scratch we would most likely use such an abstraction from the start, and there's no reason not to do so with new core features if practical. Except, of course, the issue with PHP dependencies. Essentially, the "isolation" of this utility is a product of its dependency flexibility, *not* the other way around. The only way such isolated elements would occur in core is if we condone the version heterogeneity you suggest for them!
--HM
Hey,
I had just twigged myself that that was what you were refering to.
Please keep in mind that my questions here are about general policies, not this particular utility.
Essentially, the "isolation" of this utility is a product of its
dependency flexibility, *not* the other way around.
Exactly. I don't see how it's relevant that this utility depends on core. This does not cause issues.
Although retro-engineering that framework into our core data classes
would be an absolute bitch
if we were rewriting MW from scratch we would most likely use such an
abstraction from
the start, and there's no reason not to do so with new core features if
practical.
This is off topic in this thread as far as I'm concerned. I fully agree though. I am not existing rewriting anything in core at all. I'm suggesting an addition that can be used by extensions for now, and later on for new features in core or for existing ones if someone chooses to migrate them to use this. This is just the same as the introduction of any new utility such as Html or the new logging classes. Except the difference in PHP version, which is what this thread is intended to be about.
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
On Sun, 12 Feb 2012 05:34:53 -0800, Jeroen De Dauw jeroendedauw@gmail.com wrote:
Hey,
I'm wondering about two things:
- When will we finally drop 5.2.x support?
- Can we have isolated components in core that require 5.3?
It's been one and a half years since the PHP guys dropped support for 5.2.x. What's still keeping us from doing so? Would dropping it in 1.20 work? That'll likely be in more then half a year from now, so over 2 years since PHP dropped support, which seems to be a very reasonable compatibility timespan (esp if you consider 5.3 will have been available for 3 years at that point). Personally I have not noticed the need for 5.2.x support in a while. 4 of my 6 last extensions require 5.3, and I only had a single person complain to me about this (which was over half a year ago IIRC). So it seems to me that people upgrading their wiki software have 5.3 already or have no problem with upgrading it.
My second question is about isolated utilities in core. With isolated I mean that although they might be using core, core does not use them. Can we at this point introduce such utilities that require 5.3, assuming there is good reason to have these utilities and that they cannot be made to work (sanely) with 5.2.x?
Cheers
-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --
It would be lovely to drop 5.2 some day soon.
From what I can remember: - We have preg_replace_callback calls all over core which use callbacks in ways that make code harder to follow since it's the only way possible to implement them in 5.2. - Our MWTidy class has an entire extra MWTidyWrapper class [http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/includes/parser/Tidy...], if we used 5.3 I would have NEVER wrote that code. I had to write that entire class just to work around the fact that we couldn't use closures. - Frankly, it would be nice to start using closures in hooks and extension callbacks. Instead of coming up with freakish function names and putting their names as callbacks. - I believe I've seen code that needed to use boilerplates in every subclass because we couldn't use LSB. - See r108194/r110124/r110126 and r109904/r109938, in continuing new code we've had to keep working around the fact that we can't use 5.3 features. - ;) It would be LOVELY to start using __DIR__.
((;) And the sooner we drop 5.2, the closer we get to one day being able to use 5.4 traits in RequestContext))
On Sun, Feb 12, 2012 at 5:34 AM, Jeroen De Dauw jeroendedauw@gmail.com wrote:
I'm wondering about two things:
- When will we finally drop 5.2.x support?
I just did a check of what Dreamhost is running, which seems to be PHP 5.2.17. Maybe they're trailing edge (after all, they still only have MediaWiki 1.16.4), but I'd bet a lot of the other hosters haven't moved to 5.3 yet.
I'd say that when the latest versions of the "stable" distros move over (Ubuntu LTS, Debian stable, RHEL/CentOS), that's a good benchmark, since that's what's likely to be common in hosting environments. Ubuntu Lucid is already at 5.3. I haven't checked Debian or RHEL.
Alternatively, it'd be better to actually survey the major general purpose hosters, though it seems that market is a little too fragmented and fluid to get a good sense of "typical".
- Can we have isolated components in core that require 5.3?
I'm not sure how that would work. Once it's in core, I imagine that dependencies would slip in.
Rob
wikitech-l@lists.wikimedia.org