Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On Fri, Mar 2, 2012 at 13:34, Pierre Joye wrote: > hi, > > It should have been done before 5.4.0 was out, but better late than never. > > I put together four options here: > > https://wiki.php.net/rfc/php53eol > > I'm in favor of option #1, as it gives enough time to our users to > migrate by reducing the maintenance period to only one year. > > Suggestions or comments welcome, The estimated time for next stable Debian release is the end of this year. Oldstable security is something between 12-18 months, so I think I can live with Option #1 (and patches I could cherry-pick from git - I cannot wait for the migration). O. -- Ondřej Surý -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Option #1 seems like a good way to go to me. On Fri, Mar 2, 2012 at 7:34 AM, Pierre Joye wrote: > hi, > > It should have been done before 5.4.0 was out, but better late than never. > > I put together four options here: > > https://wiki.php.net/rfc/php53eol > > I'm in favor of option #1, as it gives enough time to our users to > migrate by reducing the maintenance period to only one year. > > Suggestions or comments welcome, > > Cheers, > -- > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
hi, On Mon, Mar 5, 2012 at 11:56 PM, Matthew Weier O'Phinney wrote: > I did, actually. I still agree with Sebastian's proposal. While the PHP > group may want to push for faster adoption, the pattern I've observed > over and over is that ISPs and distributions -- particularly those with > LTS offerings -- There is no nothing of LTS, and I do not think there will ever be, in PHP. But yes, that's the role of the distributions to do it. > tend to adopt a minor version only when the new minor > version supplanting it has been released. Does it make sense? No. Is it > what happens? Yes. This behavior, and from a distribution point of view, has been based on their experiences with our relatively poor releases process or quality (from a BC point of view and other related things). The fact that debian was already planing 5.4 for debian-next before 5.4 was even final shows that this is what they expect. I got the same feedback from ISPs or other distributions. Indeed one or the other may prefer longer time frames, or some details changed, but all in all they like what we do now. It is also important to move forward and consider what we have now to take decisions and not what we have been doing or what has been done. Things change, if we don't see it we can't expect our users to see it either. > As such, I think it makes a lot of sense to base the > lifetime of 5.3 based on when 5.4 is released. 5.4 was released on March, 1st. That's why I asked this question now while it should have been done before. Cheers, -- 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 2012-03-05, Pierre Joye wrote: > On Mon, Mar 5, 2012 at 9:53 PM, Matthew Weier O'Phinney > wrote: > > > +1. > > Votes are for later. This was an indication of being in favor of the proposal, no more, no less. > > Since so many distros and ISPs tend to adopt late, this would keep them, > > and their users, covered for a reasonable time period, allowing for a > > cleaner migration path. > > There is a clear migration path defined now for all releases beginning > from 5.4. The discussion here is about 5.3 only. > > Please read all posts or replies, it helps to get the whole idea and > avoid repetitive arguing :) I did, actually. I still agree with Sebastian's proposal. While the PHP group may want to push for faster adoption, the pattern I've observed over and over is that ISPs and distributions -- particularly those with LTS offerings -- tend to adopt a minor version only when the new minor version supplanting it has been released. Does it make sense? No. Is it what happens? Yes. As such, I think it makes a lot of sense to base the lifetime of 5.3 based on when 5.4 is released. For the record, it's the path we're taking with ZF as well -- lifetime for the last minor release of ZF v1 will be determined by when ZF2-stable is released. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On Mon, Mar 5, 2012 at 9:53 PM, Matthew Weier O'Phinney wrote: > +1. Votes are for later. > Since so many distros and ISPs tend to adopt late, this would keep them, > and their users, covered for a reasonable time period, allowing for a > cleaner migration path. There is a clear migration path defined now for all releases beginning from 5.4. The discussion here is about 5.3 only. Please read all posts or replies, it helps to get the whole idea and avoid repetitive arguing :) Cheers, -- 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 2012-03-02, Sebastian Bergmann wrote: > 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. +1. Since so many distros and ISPs tend to adopt late, this would keep them, and their users, covered for a reasonable time period, allowing for a cleaner migration path. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Hi! https://wiki.php.net/rfc/php53eol I'm undecided between 1+2 and 2 for both. I guess it depends on adoption of 5.4 and progress with 5.5... Side note: looking at the new email subjects, spent some time wondering why we have this huge thread discussing line endings on the list and what's so special about them in 5.3 :) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Hi! Would it be worth while to discuss the possibility of LTS releases (Long Term Support) with 5 or 7 year support (from time of initial release)...? It is fine to discuss it and you can still support PHP 4 now if you want to, but who's going to be doing it otherwise? I wouldn't really want to spend time on fixing 7-year-old PHP version (that'd be like 4.4 now). So we need to approach it with the view of the resources we have. I hope move to Git will make the technical part much easier (merging patches between branches in git is like 2 orders of magnitude faster), but still one has to spend time on backporting, etc. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
2012/3/2 Johannes Schlüter : > So to sum it all up: I would prefer to promise security fixes only to > the outside (2 years if people here think that's a good time) and then, > as a group, agree to do additional bug fixing during that time. So, to sum it one step further, option #1 -- 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Kris Craig 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! =) Certainly I can see many people who have only just finally updated thing to work on PHP5.3 might well skip 5.4 and then look to another update when 5.5 comes out. Stopping security updates on 5.3 and then not providing 5.5 for another couple of months while not particularly problematic does seem to be a little irritating, but a fixed timetable that should provide an overlap would be ideal ... with the flexibility to move the deadline if there IS some major reason that 5.5 has not been released as currently planned? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Hi,
the primary goal should be to encourage people to move to 5.4 as soon as
possible. The clear marketing message should be along the lines of "PHP
5.4 is the best version there is, it has all of 5.3's bug fixes and
additional improvements". We have to drive the 5.4 adoption.
I also don't think it's a "till that date all kinds of fixes and from
then on suddenly security only" thing. For one due to the fact that
there are always enough corner cases and for the second that regular bug
fixing will phase out naturally ("Oh this is such a corner case I won't
validate it on 5.3, rather spend time on the next bug"). If we force
developers too much to verify and fix on multiple trees they either
blindly commit without testing[1] or don't fix bugs at all. In the end
most contributors do this voluntarily for fun (or ego or ...).
So to sum it all up: I would prefer to promise security fixes only to
the outside (2 years if people here think that's a good time) and then,
as a group, agree to do additional bug fixing during that time.
johannes
[1] Remember the PHP 6 story: There were enough commits 1:1 from 5.2
applied which sometimes didn't even compile.
On Fri, 2012-03-02 at 13:34 +0100, Pierre Joye wrote:
> hi,
>
> It should have been done before 5.4.0 was out, but better late than never.
>
> I put together four options here:
>
> https://wiki.php.net/rfc/php53eol
>
> I'm in favor of option #1, as it gives enough time to our users to
> migrate by reducing the maintenance period to only one year.
>
> Suggestions or comments welcome,
>
> Cheers,
> --
> 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
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 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 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 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 >
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
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 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 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
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 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 > >
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
hi Sebastian, Thing is that we already have well defined lifecycle for anything after 5.4. So the question is only about 5.3. That's why, given that it is already a couple of years old, I would rather go with a statically defined EOL now. As php-next is very unlikely to be the moment where people will suddenly migrate. For any future release, it is static, release date + three years. On Fri, Mar 2, 2012 at 5:44 PM, Sebastian Bergmann wrote: > On 03/02/2012 10:54 AM, Pierre Joye wrote: >> >> And when do you think it is one year after php-next? In two years. So >> much about one year being the only option ;-) > > > I am capable of learning, but that's besides the point. The point is > static (two years after release) vs. dynamic (one year after next > release). In a perfect world those two are the same. > > > -- > Sebastian Bergmann Co-Founder and Principal Consultant > http://sebastian-bergmann.de/ http://thePHP.cc/ > > -- > 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 03/02/2012 10:54 AM, Pierre Joye wrote: And when do you think it is one year after php-next? In two years. So much about one year being the only option ;-) I am capable of learning, but that's besides the point. The point is static (two years after release) vs. dynamic (one year after next release). In a perfect world those two are the same. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
they are totally unrelated. The discussion here is not about whether next will be late but when 5.3 will end. The key here is not the date itself but the ability for hosting companies, distros, etc. to plan a migration or an EOL. One or two months less or more do not change anything, as long as the support of a given branch is inside the plan (three years from every new release from 5.4 and later). On Fri, Mar 2, 2012 at 5:14 PM, Ferenc Kovacs wrote: > > > On Fri, Mar 2, 2012 at 5:06 PM, Pierre Joye wrote: >> >> On Fri, Mar 2, 2012 at 5:04 PM, Ferenc Kovacs wrote: >> >> > that's just the schedule >> >> Yes, and as of now this is the plan. The idea is the same, that does >> not affect the EOL of 5.3 is php-next is a month late, not at all. >> > > yep, and I explained why I think that it is a bad idea if the releases and > the EOLs can shift apart. > > -- > Ferenc Kovács > @Tyr43l - http://tyrael.hu -- 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On Fri, Mar 2, 2012 at 5:06 PM, Pierre Joye wrote: > On Fri, Mar 2, 2012 at 5:04 PM, Ferenc Kovacs wrote: > > > that's just the schedule > > Yes, and as of now this is the plan. The idea is the same, that does > not affect the EOL of 5.3 is php-next is a month late, not at all. > > yep, and I explained why I think that it is a bad idea if the releases and the EOLs can shift apart. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On Fri, Mar 2, 2012 at 5:04 PM, Ferenc Kovacs wrote: > that's just the schedule Yes, and as of now this is the plan. The idea is the same, that does not affect the EOL of 5.3 is php-next is a month late, not at all. Cheers, -- 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On Fri, Mar 2, 2012 at 4:54 PM, Pierre Joye wrote: > hi Sebastian, > > On Fri, Mar 2, 2012 at 4:41 PM, Sebastian Bergmann > wrote: > > 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? > > And when do you think it is one year after php-next? In two years. So > much about one year being the only option ;-) > > that's just the schedule, if the php-next is being late(which can happen, 3-4 additional RC can cause a 2 month delay), that will force us to either prolong the support of php-old (which would be in contrast with the RFC) or the dates would start shifting apart. if the next-next is also delayed 2 month, then it will be only an 8 months gap between the release of php-next and the EOL of php-old, and I think that would be a trend, because projects tend to being late. so I would support Sebastian's proposal, and there are other projects doing this kind of schedule (debian and fedora comes to mind, but I'm sure there are plenty of others) -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
hi Sebastian, On Fri, Mar 2, 2012 at 4:41 PM, Sebastian Bergmann wrote: > 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? And when do you think it is one year after php-next? In two years. So much about one year being the only option ;-) Cheers, -- 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
I like that. That way there will always be 2 stable maintained versions, and possibly a third (depending on timing) that's security only... Solves the problem quite nicely IMHO... Anthony On Fri, Mar 2, 2012 at 10:41 AM, Sebastian Bergmann wrote: > 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. > > > -- > Sebastian Bergmann Co-Founder and Principal Consultant > http://sebastian-bergmann.de/ http://thePHP.cc/ > > -- > 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
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. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Am 02.03.2012 15:15, schrieb Sebastian Bergmann: On 03/02/2012 08:34 AM, Simon Schick wrote: It's really hard to make a decision here because you also have to care about big companies in one way, that have not updated to PHP 5.3 now Such companies are using LTS releases of their OS distribution (RHEL, SLES, ...) where the vendor will take care of backporting PHP fixes. SLES 11 SP2 got out this week, finally shipping PHP 5.3 for the first time. They did a pretty good job maintaining their 5.2 product (which is still included as an unsupported option). Enterprise distributions are both slow and stable. I don't think php development should commit to unpaid long term support. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: l...@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 03/02/2012 08:34 AM, Simon Schick wrote: It's really hard to make a decision here because you also have to care about big companies in one way, that have not updated to PHP 5.3 now Such companies are using LTS releases of their OS distribution (RHEL, SLES, ...) where the vendor will take care of backporting PHP fixes. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 03/02/2012 07:34 AM, Pierre Joye wrote: https://wiki.php.net/rfc/php53eol One year with bugs fixes (both security and normal bugs) seems to be the only feasible option to me. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Hi, all It's really hard to make a decision here because you also have to care about big companies in one way, that have not updated to PHP 5.3 now ... But instead of that I read some posts from November last year that they have PHP6 in their control-panel, what is basically PHP 5.4 beta ... 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. Bye Simon 2012/3/2 Adam Harvey > On 2 March 2012 21:05, Gustavo Lopes wrote: > > Fair enough. Option #1 seems the most appropriate then. The others seem > too > > drastic to implement with such short notice. > > +1. We can't drop bug fixes immediately without warning, and I don't > think the overhead of backporting security fixes is too onerous for > one additional year, particularly in light of how significant a > release PHP 5.3 was. > > Adam > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On Fri, Mar 2, 2012 at 2:43 PM, Adam Harvey wrote: > On 2 March 2012 21:34, Simon Schick 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 > > I'm OK for option #1 The RM should have things to tell from their side and from past experiences. About LTS, I think it's not our job. Any company that would need LTS should just ask for it from its OS Support, that's their job. Julien.P
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 2 March 2012 21:34, Simon Schick 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
btw, thanks for those who keep the discussion focused on 5.3 EOL :-) For the votes, the votes phase will begin next week :) On Fri, Mar 2, 2012 at 2:12 PM, Adam Harvey wrote: > On 2 March 2012 21:05, Gustavo Lopes wrote: >> Fair enough. Option #1 seems the most appropriate then. The others seem too >> drastic to implement with such short notice. > > +1. We can't drop bug fixes immediately without warning, and I don't > think the overhead of backporting security fixes is too onerous for > one additional year, particularly in light of how significant a > release PHP 5.3 was. > > Adam -- 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On 2 March 2012 21:05, Gustavo Lopes wrote: > Fair enough. Option #1 seems the most appropriate then. The others seem too > drastic to implement with such short notice. +1. We can't drop bug fixes immediately without warning, and I don't think the overhead of backporting security fixes is too onerous for one additional year, particularly in light of how significant a release PHP 5.3 was. Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On Fri, Mar 2, 2012 at 2:00 PM, Anthony Ferrara wrote: > Would it be worth while to discuss the possibility of LTS releases > (Long Term Support) with 5 or 7 year support (from time of initial > release)...? > > 5.3 is 2.5 years old now. Which means depending on the option that's > chosen here, it'll be completely out of support a mere 3.5 to 4.5 > years after initial release. For a platform or program, that's fine. > But for a programming language, that seems a bit... short. > > Instead, I'd like to see at least one current release be "LTS", or > "extended support" which would then be covered by security fixes (at > the very least) for at least 5, and possibly 7 or even 10 years after > initial release. > > If you think it's worth talking about, I'll whip up an RFC to go over > what I mean and more justification for it... > > there was a discussion about using lts versions: http://www.mail-archive.com/internals@lists.php.net/msg51086.html http://www.mail-archive.com/internals@lists.php.net/msg50773.html but there were no consensus about it. I think that we don't need an "new" RFC, we just need to answer the same questions which was just "skipped" (basically discussed to the death, but we couldn't reach a conclusion) back then: - how many concurrent releases do we want/can support - do we need lts releases, if so then how will we chose that -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On Fri, 02 Mar 2012 14:00:51 +0100, Pierre Joye wrote: On Fri, Mar 2, 2012 at 1:56 PM, Gustavo Lopes wrote: I'd go with another option: One year of bug fixes, one year of security fixes and bug fixes that are trivial to backport. Won't work. It is then two years bug fixing. The idea of security only is to reduce both the amount of work and the risk to break it inadvertently. The truth is most of the time is less trouble to just merge the fix to oldstable than 1) determine if the bug is possibly exploitable 2) ask the RM for approval One has to do both anyway already. We have to request CVE for security issues and to ask RM for invasive fixes. Fair enough. Option #1 seems the most appropriate then. The others seem too drastic to implement with such short notice. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Hi, We already discussed LTS On Fri, Mar 2, 2012 at 2:00 PM, Anthony Ferrara wrote: > Would it be worth while to discuss the possibility of LTS releases > (Long Term Support) with 5 or 7 year support (from time of initial > release)...? > > 5.3 is 2.5 years old now. Which means depending on the option that's > chosen here, it'll be completely out of support a mere 3.5 to 4.5 > years after initial release. For a platform or program, that's fine. > But for a programming language, that seems a bit... short. > > Instead, I'd like to see at least one current release be "LTS", or > "extended support" which would then be covered by security fixes (at > the very least) for at least 5, and possibly 7 or even 10 years after > initial release. It has been discussed already and it is impossible to do from our sides. RHEL, SEL or other distros do that on their side. For us, https://wiki.php.net/rfc/releaseprocess matters now. And the idea is how can we make 5.3 fits into that while having released before this RFC was approved. Please keep in mind that no matter the option, we will be over 3 years, that's pretty good (given too that 5.4 is almost 100% BC). Cheers, -- 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On Fri, Mar 2, 2012 at 1:56 PM, Gustavo Lopes wrote: > I'd go with another option: > > One year of bug fixes, one year of security fixes and bug fixes that are > trivial to backport. Won't work. It is then two years bug fixing. The idea of security only is to reduce both the amount of work and the risk to break it inadvertently. > The truth is most of the time is less trouble to just merge the fix to > oldstable than > 1) determine if the bug is possibly exploitable > 2) ask the RM for approval One has to do both anyway already. We have to request CVE for security issues and to ask RM for invasive fixes. Cheers, -- 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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Would it be worth while to discuss the possibility of LTS releases
(Long Term Support) with 5 or 7 year support (from time of initial
release)...?
5.3 is 2.5 years old now. Which means depending on the option that's
chosen here, it'll be completely out of support a mere 3.5 to 4.5
years after initial release. For a platform or program, that's fine.
But for a programming language, that seems a bit... short.
Instead, I'd like to see at least one current release be "LTS", or
"extended support" which would then be covered by security fixes (at
the very least) for at least 5, and possibly 7 or even 10 years after
initial release.
If you think it's worth talking about, I'll whip up an RFC to go over
what I mean and more justification for it...
Thanks,
Anthony
On Fri, Mar 2, 2012 at 7:47 AM, Pierre Joye wrote:
> fixed
>
> On Fri, Mar 2, 2012 at 1:45 PM, Keloran wrote:
>> isnt option3 and option1 the same ? (unless i cant read properlly {very
>> possible})
>>
>> On Fri, Mar 2, 2012 at 12:34 PM, Pierre Joye wrote:
>>>
>>> hi,
>>>
>>> It should have been done before 5.4.0 was out, but better late than never.
>>>
>>> I put together four options here:
>>>
>>> https://wiki.php.net/rfc/php53eol
>>>
>>> I'm in favor of option #1, as it gives enough time to our users to
>>> migrate by reducing the maintenance period to only one year.
>>>
>>> Suggestions or comments welcome,
>>>
>>> Cheers,
>>> --
>>> 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
>>>
>>
>
>
>
> --
> 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
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
On Fri, 02 Mar 2012 13:34:21 +0100, Pierre Joye wrote: hi, It should have been done before 5.4.0 was out, but better late than never. I put together four options here: https://wiki.php.net/rfc/php53eol I'm in favor of option #1, as it gives enough time to our users to migrate by reducing the maintenance period to only one year. I'd go with another option: One year of bug fixes, one year of security fixes and bug fixes that are trivial to backport. The truth is most of the time is less trouble to just merge the fix to oldstable than 1) determine if the bug is possibly exploitable 2) ask the RM for approval 3) merge the fix 4) probably then you also have to remove the entry from stable NEWS to oldstable NEWS Plus, 5.3 won't accumulate known bugs so quickly. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
fixed
On Fri, Mar 2, 2012 at 1:45 PM, Keloran wrote:
> isnt option3 and option1 the same ? (unless i cant read properlly {very
> possible})
>
> On Fri, Mar 2, 2012 at 12:34 PM, Pierre Joye wrote:
>>
>> hi,
>>
>> It should have been done before 5.4.0 was out, but better late than never.
>>
>> I put together four options here:
>>
>> https://wiki.php.net/rfc/php53eol
>>
>> I'm in favor of option #1, as it gives enough time to our users to
>> migrate by reducing the maintenance period to only one year.
>>
>> Suggestions or comments welcome,
>>
>> Cheers,
>> --
>> 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
>>
>
--
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
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
isnt option3 and option1 the same ? (unless i cant read properlly {very
possible})
On Fri, Mar 2, 2012 at 12:34 PM, Pierre Joye wrote:
> hi,
>
> It should have been done before 5.4.0 was out, but better late than never.
>
> I put together four options here:
>
> https://wiki.php.net/rfc/php53eol
>
> I'm in favor of option #1, as it gives enough time to our users to
> migrate by reducing the maintenance period to only one year.
>
> Suggestions or comments welcome,
>
> Cheers,
> --
> 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
>
>
Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL
Hi Pierre, Option 1 and 3 are the same ;-) Option 1 One year with bugs fixes followed by one year with security fixes only Option 2 Two years with security fixes only Option 3 One year with bugs fixes followed by one year with security fixes only Option 4 One year with security fixes only Michael On Mar 2, 2012, at 1:34 PM, Pierre Joye wrote: > hi, > > It should have been done before 5.4.0 was out, but better late than never. > > I put together four options here: > > https://wiki.php.net/rfc/php53eol > > I'm in favor of option #1, as it gives enough time to our users to > migrate by reducing the maintenance period to only one year. > > Suggestions or comments welcome, > > Cheers, > -- > 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 > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] discussions, about a 5.3 EOL
hi, It should have been done before 5.4.0 was out, but better late than never. I put together four options here: https://wiki.php.net/rfc/php53eol I'm in favor of option #1, as it gives enough time to our users to migrate by reducing the maintenance period to only one year. Suggestions or comments welcome, Cheers, -- 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
