Ok, I'm up to speed now. I agree that Option 1 is the best approach. --Kris
On Fri, Mar 2, 2012 at 10:58 AM, Pierre Joye <pierre....@gmail.com> wrote: > 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 >
