3 ms·

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

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.

AgentConundrum 14y ago
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.
jerf 14y ago
"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.
- rbanffy 14y ago
  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.
  - MartinCron 14y ago
    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.
    - rbanffy 14y ago
      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.

AgentConundrum 14y ago

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.

jerf 14y ago

"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.

rbanffy 14y ago
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.
- MartinCron 14y ago
  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.
  - rbanffy 14y ago
    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.