again, we have a clear EOL process now for 5.4 and later. Only 5.3 does not have any. We have to define it now instead of doing it in 1-2 years without giving our users any kind of reasonable delay to plan a migration.
Cheers, On Fri, Mar 2, 2012 at 7:54 PM, Kris Craig <kris.cr...@gmail.com> wrote: > I'm probably missing something, but why not just do it like we did with > 5.2? I.e. we keep maintaining it until PHP 5.5, at which time we deprecate > it and be done with it? > > Like I said, I'm probably missing something lol, so if someone could > explain why this is different I'd be much obliged! =) > > --Kris > > > On Fri, Mar 2, 2012 at 9:39 AM, Clint Byrum <cl...@ubuntu.com> wrote: > >> Excerpts from Sebastian Bergmann's message of Fri Mar 02 07:41:53 -0800 >> 2012: >> > On 03/02/2012 07:34 AM, Pierre Joye wrote: >> > > https://wiki.php.net/rfc/php53eol >> > >> > I discussed with Arne Blankerts and Stefan Priebsch over breakfast >> today >> > and Stefan had an interesting idea: why not announce (now) that PHP 5.3 >> > will go into EOL a year after PHP 5.5 comes out? >> > >> > * Now until PHP 5.5 comes out: bug and security fixes for PHP 5.3 >> > * From the release of PHP 5.5: security fixes for PHP 5.3 for a year >> > >> > Ideally, PHP 5.5 would be out in a year from now, so it would come down >> > to one year of bug and security fixes and one year of security fixes >> > only. Makes sense to me. >> > >> >> Just chiming in from the Ubuntu side of things. I think this is the most >> predictable, and helpful plan for users and for distributors. >> >> From the user standpoint, its quite useful to know where you stand >> for upgrade path. This should make conservative users comfortable with >> using 5.3 on existing projects until 5.5 enters RC phase, and then they >> can start evaluating their options to move to 5.5 or 5.4, as they know >> they'll have a whole year to evaluate 5.5. If you put a clock on 5.3, >> and 5.5 slips for legitimate reasons, then they'll be stuck with 5.4 >> only, and you may actually *miss* the opportunity to get people on the >> latest release. >> >> From a distribution standpoint, anything that lengthens the amount of time >> that PHP as a project fully supports a release makes our burden smaller, >> and gives our users a better chance at having stable software for the >> entire life of our LTS releases. Selfish, I know, but just stating the >> obvious fact. >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
