Live data from Hacker News

PHP 5.5

github.com

11–20 of 112 posts

Re: PHP 5.5

#11

They added coroutines in a minor number patch. wat.

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 exception is probably ruby which greatly broke backwards-compatibility with 1.9 (unicode) and mostly just changed internals with 2.0

Re: PHP 5.5

#13
post #11

They added coroutines in a minor number patch. wat.

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?

Re: PHP 5.5

#14

They added coroutines in a minor number patch. wat.

PHP's versioning has generally been a bit weird since the abortive PHP 6 project. PHP 6 was meant to be the version that implemented full unicode support, but this proved to be very difficult, with the result that major new features had to go into the 5.x branch while 6.x remained in development (which, I guess, it still is).

5.3 added closures and 5.4 added traits, so adding coroutines in 5.5 is not inconsistent with past behaviour. I guess it's sort-of like how every version of OSX is 10.x, even though there have been massive changes between 10.0 and 10.8; it makes more sense to think of 10.8 as being 'OSX version 8'. Likewise 'PHP5' has been around for so long that nobody really looks at the major version number any more.

Re: PHP 5.5

#15

They added coroutines in a minor number patch. wat.

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/

Re: PHP 5.5

#16
post #11

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?

Actually, I think it's fine for languages:

Backwards-Incompatible change? Increment Major version

Many new features, but (largely) backwards compatible? Increment Minor version.

Bugfixes? Increment Patch.

I think this also perfectly maps to Semantic Versioning (http://semver.org/)

Re: PHP 5.5

#18

They added coroutines in a minor number patch. wat.

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 between different versions of 5.x is not really correct. From a features perspective I think this is a good thing - PHP needs to move forward - but it's wrong to say that PHP entirely follows the SemVer standard.

Re: PHP 5.5

#19

Am I the only one thinking PHP needs more stuff removed rather than added ?

If you mean deprecation and then removal, yes. Search for deprecation in the changelog to see that it's happening already! ;)
Post reply on HN