21–30 of 112 posts
Am I the only one thinking PHP needs more stuff removed rather than added ?
Removing stuff from a programming language has virtually no benefit and a huge real economic cost. That, of course, is under the assumption that the programming language has users.
I could see them deprecating some stuff, and adding yet another E_EVEN_STRICTER level that tosses ugly notifications when deprecated things are done. That would be nice.
Earlier quoted context omitted.
This is standard in PHP's release process [0]. New features are fine, as long as they don't break backwards compatibility. This is the same as semantic versioning [1]. [0] https://wiki.php.net/rfc/releaseprocess [1] http://semver.org/
Except that PHP's 'minor' version changes do break backwards-compatibility: http://www.php.net/manual/en/migration55.incompatible.php http://www.php.net/manual/en/migration54.incompatible.php http://www.php.net/manual/en/migration53.incompatible.php http://www.php.net/manual/en/migration52.incompatible.php As someone who has maintained open source software for PHP, the idea that there's backwards-compatibility betwee…
Breaking changes in each is fine.
They added coroutines in a minor number patch. wat.
The minor number in PHP does not mean bugfixes and small stuff only, as does in some project. The second even minor-er (!) number (.x.y) is for that.
PHP has always added tons of stuff in .x releases (closures are another example).
Python also adds major features in minor versions all the time. You can find similar grand changes between 2.x releases.
Now I just have to wait my ISP would eventually some day upgrade from 5.3.
Earlier quoted context omitted.
Just as rails has added the asset pipeline in a minor number patch. Or as ruby changed to unicode with 1.9. Or as python added a whole new syntax for exceptions with 2.6. As with many other languages, incrementing the minor number usually means quite big changes while more or less keeping backwards compatibility. Changing the major number is something that's done when backwards-compatibility is hugely affected. The e…
Oh, I'm not about to hold up ruby or python as shining beacons here--though I will smugly admit that the rubyists seem to be pretty fast at updating their gems. Still, it's weird practice nonetheless, right?
No, it depends on the versioning number scheme. Not all schemes mean the same thing with major/minor/minorer.
Earlier quoted context omitted.
Only if you're using them in the first place. Most people deploy in Linux. Hence, totally irrelevant for them.
Deploy yes, but not develop with. Most people don't really use virtual machines (vagrant and friends) if they have XP.
Seems like a bunch of really welcome improvements. Wish I hadn't known about them though, as I probably won't be able to use them in our production environment for the next 2 years or so.
Earlier quoted context omitted.
Except that PHP's 'minor' version changes do break backwards-compatibility: http://www.php.net/manual/en/migration55.incompatible.php http://www.php.net/manual/en/migration54.incompatible.php http://www.php.net/manual/en/migration53.incompatible.php http://www.php.net/manual/en/migration52.incompatible.php As someone who has maintained open source software for PHP, the idea that there's backwards-compatibility betwee…
5.x releases are bigger than the versioning suggests, the 5 series is likely 10 years old now? Breaking changes in each is fine.
To be honest, I don't really care about following SemVer exactly. And PHP does follow SemVer if you pretend that the major version number doesn't exist, and the minor version number is really the major one (hence we're just seeing the release of version 5.0 of 'PHP5', rather than 5.5.0 of 'PHP'). This is all pretty easy to understand and it's not a bad way of doing things, but claims that PHP follows SemVer are incorrect and will cause confusion.