-2

This risks offending some. I don't mean to. I'm seriously wondering about this. And it's not at all specifically about PHP; it's just that this is such a major, critical software project which is beyond important to me.

Yesterday, PHP 8 was finally released as "GA" ("General Availability"). That means it has gone through numerous alpha, then beta, then "release candidate" stages, each one supposedly being tested by tons of people all over the world.

As soon as I had updated (from 7.4.12), the error log started getting flooded with errors related to imap_msgno() and Bad message number. I've already separately asked about this specific issue, searched around all over, and tried to solve it myself by wasting hours upon hours of my time and energy trying to at least temporarily "patch" it. Nothing works. It makes no sense. The error shouldn't exist.

Reading the changelog, nothing indicates any changes to this function. Yet my code worked perfectly for years with tons of different PHP versions, until now with PHP 8.

This seems like something which must have been found out if people actually test the pre-GA releases of PHP. But do they actually?

Or is this just a "show" which looks good but in reality, only an extremely small number of people ever run these pre-release, unstable versions?

I don't blame them -- after all, I don't, myself. And for good reasons. I don't want to subject my data to horrible bugs and glitches which corrupt/leak/mess with it. But somebody must do it... right?

This is not the first time that this happens. Some version of PHP 7 caused a pretty serious glitch which also seems to me like it would've been found out if people had actually tried it before the "sharp" release.

Again, I'm not complaining that others aren't subjecting themselves (and their users/dependents) to all this pain to spare me from it. I'm just very skeptical to the idea that there's this large, enthusiastic crowd all over the world hard-testing each release.

This is particularly unfortunate because it's a new MAJOR version of the language. I was genuinely very excited for this long-awaited milestone, and now it feels awful if I have to downgrade back to 7.4.12 and wait for 8.1 or something for this bug to be fixed. The IMAP functions are not obscure but integral for many, and I don't even understand how a bug like this can happen when there were no changes to the functions I use.

Improve this question
5
  • 5
    I’m voting to close this question because nothing useful can come from a discussion based on one single anecdote. Commented Nov 27, 2020 at 5:56
  • @peterh-ReinstateMonica Yeah, like Python, right? Don't make me laugh. There are no such "another languages" which aren't far worse. Commented Nov 27, 2020 at 10:14
  • Take a look at the PHP bugtracker, search for all tickets related to Version 8.0.0 and you'll find that there are barely any results (~150 at the time of writing this comment), at least considering the size of the project. This leaves 3 options: a) PHP 8 has remarkably few bugs, b) there aren't actually that many people who have tested it, or c) a lot of people who found bugs haven't reported them. Speaking of which: did you report that bug? Commented Nov 27, 2020 at 10:58
  • 2
    "This is particularly unfortunate because it's a new MAJOR version of the language." - The kind of compatibility problem you are describing should be expected with any major update of any major programming language or tool. It's not unique to open source, but it's common for such developer tools in general. That's why the convention exists, to update the major version number (e.g. 7 to 8) to give a hint that things may work differently now. If you are relying on version 7 behaviour, then you have the option to stay on that version. Commented Nov 27, 2020 at 11:14
  • I removed my comments. While I still believe these are right, I think saying it on this way is contraproductive. Commented Nov 27, 2020 at 12:43

1 Answer 1

Reset to default
2

I'm not sure this question is going to survive the community much longer, but I personally think it contains a genuine question that admits of an answer.

PHP8 isn't in any major distro yet (that I'm aware of). I see that some custom build repositories like Remi's Repo have it available, but it's not the default version even for users of those repos; it'll be some months, I should think, before PHP8 makes it through the distros' slow-turning wheels into major use. If you were complaining about having just installed Fedora 35 (which I am assuming will be the first version of Fedora to carry PHP8, and which won't release until October 2021, ceteris paribus) then my answer might be somewhat different.

Software has bugs; it's a fact of life. As the distro people import these new versions, and their development communities (the rawhide users, Remi's users, and the like) find the bugs, more fixes will make their way back to upstream. By the time it's been through that mill, the PHP that makes it out to ordinary end-users like me will be much refined. That is the free software life-cycle; you seem to be confusing it with the life-cycle of commercial software (though in my experience that often goes general-release with some pretty nasty bugs in it, which is why seasoned sysadmins don't install .0 versions of anything on production kit).

I say all this not to make light of your frustration, but to clarify that by downloading and building PHP8 on the day of general release, you are an early-adopter.

it has gone through numerous alpha, then beta, then "release candidate" stages, each one supposedly being tested by tons of people all over the world

Who, exactly, are these tons of people supposed to be? We've established that, by the normal lifecycle and release flow of free code, you're an early adopter. PHP8 has been available in one form or another since 8.0.0alpha1 on 23 June, but if I understand you correctly this is the first time you've tried to engage with it. You are exactly the sort of person whose ability and experience would have been invaluable to the project for building alpha, beta, and release-candidate versions and feeding experiences and bug reports back.

As with nearly every other group of free software developers, the PHP people aren't malicious, slipshod, or uninterested; they wouldn't knowingly and deliberately ship general-release code that had show-stopper bugs in it. But they're only human, and can test only a finite number of scenarios on a finite number of setups. Every project relies on a peripheral circle of people who have the interest and ability to build development versions and test them in their own setups, feeding back the bugs they find so they can be reproduced, triaged, and hopefully fixed.

I take your point about not wanting to corrupt your data, but (a) I really hope you have backups, because dodgy versions of PHP aren't the only things that can corrupt it, and (b) virtualisation/containerisation is now routine, and allows everyone and his dog to have development copies of their production environments, which are ideal for testing this sort of thing.

I think my point is: you're exactly the sort of person who has the ability and the desire to build and test development versions of PHP. If you aren't engaging with the PHP development process, what makes you think there are thousands of other people with the same skillset who will?

Improve this answer
2
  • "virtualisation/containerisation is now routine" is news to me. If you are talking about Docker, that program might as well be vaporware; I've never been able to get it to function in any manner. As for the rest of your answer, I'm confused by how you (in spite of quoting me) seem to think that I'm using some early beta, when it's the "stable/final" PHP 8 that was released yesterday. What exactly do Linux distros have to do with PHP's development? Commented Nov 27, 2020 at 9:55
  • 1
    @Skeeter I routinely spin up C7 and C8 VMs for almost anything I wish to test, since it adds about five minutes to the workflow, and allows me to test builds, installs, and reconfigs with nearly no production risk; I am by no means alone in doing this. My point about the general release version is that it's not at the end of its life in the free software development chain, but merely one step further on. It will get picked up by custom repos, then mainstream repos, then become default, all the time getting further refined. At the end of that chain, it will be where you now think it is. Commented Nov 27, 2020 at 10:00

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.