# [RFC] discussions, about a 5.3 EOL - Thread: https://externals.io/message/58469 - Original archive: https://news-web.php.net/php.internals/58469 - Started by Pierre Joye on 2012-03-02T12:34:21+00:00 - Messages: 48 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/58469.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #58469 — Pierre Joye — 2012-03-02T12:34:21+00:00 URL: https://externals.io/message/58469#58469 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 --- ## #58470 — Michael Kliewe — 2012-03-02T12:45:42+00:00 URL: https://externals.io/message/58469#58470 · In reply to: #58469 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 > 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 --- ## #58471 — Keloran — 2012-03-02T12:45:54+00:00 URL: https://externals.io/message/58469#58471 · In reply to: #58469 isnt option3 and option1 the same ? (unless i cant read properlly {very possible}) > 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 --- ## #58472 — Pierre Joye — 2012-03-02T12:47:35+00:00 URL: https://externals.io/message/58469#58472 · In reply to: #58471 fixed > isnt option3 and option1 the same ? (unless i cant read properlly {very > possible}) > > > > […] > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #58475 — Gustavo Lopes — 2012-03-02T12:56:58+00:00 URL: https://externals.io/message/58469#58475 · In reply to: #58469 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 --- ## #58476 — Anthony Ferrara — 2012-03-02T13:00:20+00:00 URL: https://externals.io/message/58469#58476 · In reply to: #58472 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 > fixed > > > > […] > > > > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #58477 — Pierre Joye — 2012-03-02T13:00:51+00:00 URL: https://externals.io/message/58469#58477 · In reply to: #58475 > 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 --- ## #58478 — Pierre Joye — 2012-03-02T13:04:30+00:00 URL: https://externals.io/message/58469#58478 · In reply to: #58476 Hi, We already discussed LTS > 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 --- ## #58479 — Gustavo Lopes — 2012-03-02T13:05:47+00:00 URL: https://externals.io/message/58469#58479 · In reply to: #58477 On Fri, 02 Mar 2012 14:00:51 +0100, Pierre Joye wrote: > On Fri, Mar 2, 2012 at 1:56 PM, Gustavo Lopes > wrote: > > > […] > > 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. > > > […] > > 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 --- ## #58480 — Ferenc Kovacs — 2012-03-02T13:11:43+00:00 URL: https://externals.io/message/58469#58480 · In reply to: #58476 > 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 --- ## #58481 — Adam Harvey — 2012-03-02T13:12:35+00:00 URL: https://externals.io/message/58469#58481 · In reply to: #58479 > 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 --- ## #58482 — Pierre Joye — 2012-03-02T13:22:33+00:00 URL: https://externals.io/message/58469#58482 · In reply to: #58481 btw, thanks for those who keep the discussion focused on 5.3 EOL :-) For the votes, the votes phase will begin next week :) > > > […] > > +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 --- ## #58487 — Simon Schick — 2012-03-02T13:34:54+00:00 URL: https://externals.io/message/58469#58487 · In reply to: #58481 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 > > > […] > too > > […] > > +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 --- ## #58483 — Adam Harvey — 2012-03-02T13:43:08+00:00 URL: https://externals.io/message/58469#58483 · In reply to: #58487 > 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 --- ## #58485 — jpauli — 2012-03-02T13:56:07+00:00 URL: https://externals.io/message/58469#58485 · In reply to: #58483 > > > […] > be > > […] > that > > […] > new > > […] > > 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 > > -- > > > > 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 --- ## #58489 — Sebastian Bergmann — 2012-03-02T14:01:36+00:00 URL: https://externals.io/message/58469#58489 · In reply to: #58469 > 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 Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #58491 — Sebastian Bergmann — 2012-03-02T14:15:35+00:00 URL: https://externals.io/message/58469#58491 · In reply to: #58487 > 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 Bergmann Co-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ --- ## #58496 — Ralf Lang — 2012-03-02T15:12:13+00:00 URL: https://externals.io/message/58469#58496 · In reply to: #58491 Am 02.03.2012 15:15, schrieb Sebastian Bergmann: > > > […] > > 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: lang@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 --- ## #58497 — Sebastian Bergmann — 2012-03-02T15:41:53+00:00 URL: https://externals.io/message/58469#58497 · In reply to: #58469 > 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/ --- ## #58498 — Anthony Ferrara — 2012-03-02T15:49:50+00:00 URL: https://externals.io/message/58469#58498 · In reply to: #58497 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 > > > […] > > >  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/ --- ## #58499 — Pierre Joye — 2012-03-02T15:54:43+00:00 URL: https://externals.io/message/58469#58499 · In reply to: #58497 hi Sebastian, > > > […] > > >  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 --- ## #58500 — Ferenc Kovacs — 2012-03-02T16:04:30+00:00 URL: https://externals.io/message/58469#58500 · In reply to: #58499 > hi Sebastian, > > On Fri, Mar 2, 2012 at 4:41 PM, Sebastian Bergmann > 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 ;-) > > 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 --- ## #58501 — Pierre Joye — 2012-03-02T16:06:44+00:00 URL: https://externals.io/message/58469#58501 · In reply to: #58500 > 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 --- ## #58502 — Ferenc Kovacs — 2012-03-02T16:14:51+00:00 URL: https://externals.io/message/58469#58502 · In reply to: #58501 > > > > […] > > 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 --- ## #58504 — Pierre Joye — 2012-03-02T16:36:42+00:00 URL: https://externals.io/message/58469#58504 · In reply to: #58502 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). > > > > > […] > > 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 --- Next page: https://externals.io/message/58469.md?page=2