Hi! > The questions here are: > * will this code break any code running with PHP before that patch? > * does this code change the language in any way?
OK, so I think there's a misunderstanding here. What you describing is exactly my position - enhancements that are a) small and b) self-contained are OK, others are not OK. This has been the case since we started the whole format release process thing. If you agree with that, then our positions are completely the same. However, it's not what Pierre's (and possibly others) position is - that position does not ask any questions, it's a blanket ban on any enhancement, without any consideration or looking into the substance of the enhancement. If it adds anything that did not exist before, however minor and safe, it is still banned. > But then using the x.y.z version schema implies something like semver No it doesn't. People used versions way before semver was even a thing, and semver does not owns versioning in any way. There are literally hundreds if not thousands of projects using this version format without any relation to semver. We may reuse the rules semver uses, when it makes sense to us, but using three-component version does not introduce any obligation to abide by what semver.org says to the letter. > Instead we should consider having a stable "PHP-next" nightly release > that is something like a stabilized master that gets all changes for the > X.Y+1 release. If you require these little features, you use that, if Who will be doing that? Who will be doing all the necessary backporting and maintenance and how it's different from just porting stable changes to stable version? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
