[RFC] discussions, about a 5.3 EOL View as Markdown

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

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:
internals@lists.php.net/msg51086.html" rel="nofollow" target="_blank">http://www.mail-archive.com/internals@lists.php.net/msg51086.html
internals@lists.php.net/msg50773.html" rel="nofollow" target="_blank">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

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

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

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

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.

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/

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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,

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

Excerpts from Sebastian Bergmann's message of Fri Mar 02 07:41:53 -0800
2012:

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.

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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

On Mon, Mar 5, 2012 at 9:53 PM, Matthew Weier O'Phinney
weierophinney@php.net 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 | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

This has to be stressed time and again, in order to start changing current
perception that upgrading to newer PHP release is a major PITA.

I suppose you mean "not anymore" :)

Then go out there to spread the new message and facts! :)

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org