Comment by kevinalexbrown | Hacker News Reader

Comment by kevinalexbrown | Hacker News Reader

Leaving aside the irony of asking Rasmus to escalate the issue (this would be like complaining in an "Ask HN:" and suggesting that pg escalate the issue up the ycombinator chain), or whether the change was logical or not, I learned something cool from one aspect of Rasmus' response:

... there are many many people out there affected by these changes, we recognize that. That is also why we are not likely to reverse a change like this that others in your situation have now accounted for, tested and deployed in production for many months ... -- rasmus.

Good decisions don't always mean everyone goes home happy. Whether or not the change was good or bad, reversing it now could negatively impact anyone else who already adjusted. If it means "MONTHS" of work for this guy, in order to save "MONTHS" of work for 100 others who use PHP, so be it.

Even if we were to take a leap of faith and assume it was a bad decision by Rasmus to make the change in the first place, it's been done. Responding to inconsistency with more changes seems like trying to regain your balance by making wilder and wilder swings of your arms.

A possible solution to this would be to put a policy together to only fix things like this in the next major version, not on the current line.

As long as it's known that these are long term fixes people can prepare for them.

You're likely talking about the general case, not the OP, but I'd just like to point out that the submitter of the bug report was jumping from 5.1.6 to 5.3.1 (not to mention changing from Solaris to Red Hat, which could have its own issues) when he found this "error". 5.x releases are de facto "major" versions, even if only the minor version number changes.

It's entirely possible that this fix was made in a point release - it didn't jump out at me in the changelog, and I didn't feel like digging - but that's a moot point in this case, since even if the change was made with a major release like 5.3 this guy would still be upset.

"The first PHP 5.3 release candidate was back in March 2009. We put these release candidates out there so people who "will have MONTHS of work" because of small changes can chime in then and make their case. The release candidate period lasted until July."

I love to hate PHP-the-language as much as the next guy, and I don't particularly love their design decisions for the language, but let's face it, on basic release management grounds there's nothing to complain about. On general principles I'm of the opinion that the PHP project did everything called for here and the fault is pretty much 100% on the user's side here, with the only possible counterargument being that they apparently may not have called this exact change out quite as precisely as they could have (though that implies they knew, which, well, in a sloppy-type language like this this sort of thing is easy to miss). Languages don't get to version 5 without some breaking changes, but the alternative of every language being stuck with every bad decision made in version 1 forever is worse.

I once played with continuous testing using a python fresh from the Hg repo. Once you set up your CI/CT box with enough compute power there is no reason to always check your product against the upstream pre-release components.

Now that I remember it, it was a pretty nice setup - creating OpenVZ partitions from a template, making python from sources and testing the application within the machine. Too bad it was a one-off thing. I should have used something like buildbot or jenkins.

That is a wonderful idea. Knowing now if your stuff will or will not break in the "future" seems worth the investment. If anyone else is doing this, I would love to see details.

There will be a couple false positives, but, in any case, you can measure the upstream development quality, and use that as an input to guide your decisions.

Responding to inconsistency with more changes seems like trying to regain your balance by making wilder and wilder swings of your arms.

A better solution? Don't make arbitrary changes that will make months of unnecessary work for people for no reason to begin with. If you're going to eat up developer time, you should make it for a good reason.

No serious developer would lose months of work to this, that claim is completely ludicrous.

"The change was part of standardizing all of PHP on the same parameter parsing code." is not an 'arbitrary change' 'for no reason'.

Even if the reason is making PHP more consistent and paying off technical debt for future PHP maintenance, instead of benefitting you directly, it's still a reasonable change for a reasonable reason.

if you can't do that trivial change on some convulated release system... You don't change php version either. Unless you are addressing security changes.

I think its very professional to not bump versions just for the sake of it.

release notes exist for a reason.

As far as I understood, the release notes were not very explicit or complete (the list of impacted functions were missing) on this issue.

Recently I have encountered a problem with redhat migration: /usr/bin/X11/xwd was "moved" to /usr/bin/xwd. I have not found anything in the release note.

It is not enough to ask people to read the release notes, these release notes should be complete and usable.

The point is that the release notes will tell you if there are security flaws fixed.

There's no substitute for actually testing your code with a new environment before deploying it.

Well, of course they must be addressing security changes! It's PHP, remember? ;)

Reply on news.ycombinator.com