Up requirements to MySQL 4.1

This makes sense to me. Per MySQL's website this support ended 31 July 06.

Therefore any bugs/security issues that could arise in MySQL 3.x are no longer supported either.

Shifting support to a minimum of 4.0 seems reasonable to me, especially since 6.x will shift this to 4.1. Seems like a logical transition: 4.7 required 3.x, 5.0 requires 4.0, and 6.0 requires 4.1.

I agree. Today, there is no reason to still use 3.23. Even 4.0 is on the edge due to its lack of UTF-8 support.

Changed the constant and committed to HEAD.

I guess http://drupal.org/requirements should be updated ?

That would be a job for http://drupal.org/node/99895

IMO this is a very irresponsible thing to do this late in the cycle.

We've gone through 2 betas and an RC with 3.23 support, no suddenly and without warning it's gone. That's a bad policy. We have to make changes like this early in the dev cycle, not at the last minute.

This was discussed several times and at length on the development mailing list. So this change wasn't exactly unexpected.

That said, it is not clear what the impact of this change is going to be. I bet a fair amount of people might still be on MySQL 3 but I have no empirical data to backup that gut feeling. It's dangerous to use that as an argument, but looking at the PHP5 adoption rate, the number might be depressing.

Discussion on the dev list is just that: Discussion. Lots of things get discussed there that don't necessarily become official. The traffic is high enough that it's difficult to keep track of and remember stuff.

What's official is code. If the code supports 3.23 right up until RC, changing that could have a very large ripple effect that is exactly the kind of thing you do not want at this stage.

If we were going to make that change we needed to do it prior to the first beta. I believe it is now too late and we should do that first thing in the Drupal 6 branch instead.

This must be rolled back.

I know it's hard to keep the freeze but such changes must not happen post freeze much less post RC1.

As merlin said, this is very bad policy.

Now come on, there is *no* reason for doing this, just that the vendor does not support it, so what? If people use it, we shall support it if it costs us nothing.

About PHP versions, my train of thought was that if this change goes through then we MUST drop support for PHP 4.3 which is not supported and require 4.4.x/5.2.x because 4.3/5.1 is no longer supported. Supporting 4.3 DOES cost us a lot: the huge Unicode property defines in search (see PHP manual: Since PHP 4.4.0 and 5.1.0, three additional escape sequences to match generic character types are available when UTF-8 mode is selected.) I will be the first to hail if we up the PHP requirement to 4.4 -- but the list consesus was that because RHEL we can not do that even in Drupal 6.

Also. I did not want to mention this in public but so be it. This is unfair. I discuss and announce version changes half year in advance (and got my hand bound with not being able to up to 4.4), and two core committers in seven hours change a version -- past RC1?

I am not debating the mailing list. If this was not done on August 30 then it was not done for Drupal 5.

Who is annyoing here? I had arguments. You answered none of them.

Again. Since when this can pass past release candidate? A version that could have been released?

My answer to that was: http://lists.drupal.org/archives/development/2006-07/msg00394.html I agreed. However. That train has left the station at latest on RC day. Yes, it would have been better if we would have actually dropped MySQL 3.23 support for 5.0. But now it's something we just can't do. And we have no technical reason to do so.

An otherwise backwards compatible API change did not went through the other day with book because it's an API change, instead we copy-paste the function.

I remember the guy who reported a big German ISP who used to this day an Apache which reported itself as 1.2 but was mostly patched up to 1.3 level by the ISP. I presume that any sufficiently big ISP or OS vendor can backport security fixes to MySQL 3.23 so the argument "There will not be any security updates for 3.23 from MySQL AB. Enough reason to drop it." argument is actually moot.

We do not win anything here. We use some user trust though.

"use" at the end is "lose" of course.

If freeze means anything, by all means, this is the kind of change that should not happen. Core gains nothing at this point by dropping support for older MySQL versions. There is no code that requires it. There is no code that takes advantage of it. And there are users who stand to lose when the required version is raised needlessly.

"We really did mean to up the required version earlier, and some of us talked about it on the mailing list" is not sufficient justification. I intended to properly support using drupal_render() on sub-chunks of the $node->content array. Some of us discussed it on the devel list. But my intention to do that doesn't mean that the change can be put in moments before the final release.

My host uses MySQL 4; I don't have a horse in the race. But if this change stays in, we have some explaining to do. Both to users who were able to use 5.0RC1 without problems, and to developers who need a clearer definition of what 'Code Freeze' actually means.

I rolled back the MySQL 4 requirement. Core works fine with MySQL 3.23 so let's be liberal and let people use it. It's not strictly a bug because nothing really breaks.

I'm going to touch base with my contacts at MySQL to figure out what the MySQL 3 marketshare looks like.

Moving this to Drupal 6.

Hooray!

I weighed in against it in 5.0, but I *do* support it for Drupal 6. This will really open up a lot of doors for query improvements.

Dries this should *NOT* be 4.0.0 but 4.1.0 -- so we can make use of subselects.

Eaton is sitting next to me and he thought 4.1 was set, not 4.0.

Agreed... 4.1 support is pursuant to the thread on devel that talked about this. It also follows with MySQL's active support lifecycle for 4.1 (ended Dec 2006): http://www.mysql.com/company/legal/lifecycle/

Looks good.

Has been committed. Thanks.

And now, we dance for joy.