On 2 March 2012 21:34, Simon Schick <simonsimc...@googlemail.com> wrote: > One or two years is way to short if you'd ask me. A major release should be > supported with all kind of bug fixes for min. 3 years after a new release > has been brought out. Specially if it's a wide-spread language like PHP that > has been implemented by such big and lazy companies. Please do not > misunderstand that. Lazy is not meant in the way that they are doing > nothing, but that it takes way more time as it does for me installing a new > PHP version on my 2-3 servers.
There has to be a limit at some point because the maintenance burden becomes too difficult. With the two year proposals, we're going to end up in a position next year where we'll have active 5.3, 5.4, 5.5, 5.6 and trunk trees (or whatever 5.5 and 5.6 get numbered). That's at least one too many, frankly, but there was always going to be some awkwardness during the transition to the new release process and I for one would prefer to err on the side of caution. Honestly, I'd probably prefer 9 months of bug fixes (up to the release of 5.5 in November/December) + 9 months of security fixes, but I don't want to muddy Pierre's RFC further, and I'd like to hear the opinions of the RMs, since this is very much on them. The point of the release process RFC was to clarify this — releases from 5.4 onwards have a clearly defined two year bug fix + one year security fix lifetime. I think that's reasonable, and it falls into line pretty well with a number of other languages. The fact that we're in this position is a one-off, and I don't think we can prolong it indefinitely (nor do we really have the resources to). Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
