When you have infinity at your disposal, skipping 6 and taking the next free number - 7 - makes a whole lot more sense than trying to rewrite the archives of history (renaming 6 to Old 6).
Similarly, while there are fairly good reasons on why we shouldn't use 6, there aren't any for the next-in-line number - 7 - so the whole question on maybe we should pick 14, Luxonda or anything else that implies we change our versioning scheme. We're not - we're just not using a version number that was already used. Zeev > On 6 ביול 2014, at 13:07, Andrea Faulds <a...@ajf.me> wrote: > > >>> On 6 Jul 2014, at 17:46, Lester Caine <les...@lsces.co.uk> wrote: >>> >>> On 06/07/14 16:08, Andrea Faulds wrote: >>> I think it’s generally clear what’s for the new PHP 6 and what’s for the >>> old; anything from after the old PHP 6 was abandoned must be about a new >>> PHP 6, and anything from before it must be about the old PHP 6. If this RFC >>> were to pass with people voting for 6, then it would be pretty clear that >>> anything coming after it was about the new PHP 6. >> >> https://www.google.co.uk/search?q=php6+site%3Abugs.php.net ... >> >> Now one can filter additional on date, but the point here is that just >> starting with the bugs list we have conflicting material that needs to >> be avoided. PHP6 WAS documented extensively even just on the web site, a >> lot of that material gets mirrored with more recent timestamps which >> makes filtering what is new and what is old a lot more difficult. Even >> PHP7 appears quite often on the website, but fortunately not too often >> in the bugs list … > > Can’t we just rename the PHP 6 category to “Old PHP 6” on bugs.php.net and be > done with it? Or does it not work like that? > -- > Andrea Faulds > http://ajf.me/ > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
