Hi! > the release process rfc (https://wiki.php.net/rfc/releaseprocess) governs > the releases since 5.4: 2+1 year of support after the initial X.Y.0 release. > as pointed out, 5.4 is already past the 2 years of bugfix support, so we > should announce it that it is on security fixes only.
5.4.32 is already in RC and will be released next week. 5.4.33-dev is already containing some non-security fixes. So we could just arbitrarily announce that starting noon today we stop accepting non-security bugfixes into 5.4, or we could choose a less arbitrary cutoff - such as release of 5.6 or 5.4.33. I would prefer the less arbitrary route, I don't see much harm in having the bugfixes last a little longer, but having more natural version succession - i.e. saying we always have 2 stable branches and one in security fixes. > process rfc and announce the extended support and EOL dates based on the > original release date, or update the releaseprocess RFC to state that we > move into extended support/EOL when the the new version in that year is > released. I think it would be more natural and accommodating for the realities of the release process. The thing is we will have delays, we will have bad RCs, we will have people going on vacations or being too busy, and having a scheme that can accept this while still preserving the general structure seems better to me than literal day-counting. If this means 5.4 has extra 1/2 year of bugfixes - I don't see big harm done by that. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
