Following the initial discussion, I prepared an RFC that proposes to extend
the support periods for PHP 5.6:
https://wiki.php.net/rfc/php56timeline
Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
omissions.
Let the discussion continue…
Zeev
It just occurred to me (too late :D sorry Zeev) that it might make sense to split this into two RFCs:
- to define the active support end date for 5.6 (e.g. "2016-08-28" or "2016-12-02" or "2016-12-31")
- to define the security support end date for 5.6, and specify that relative to the active support end date only (e.g. "12 months after active support end date" or "24 months after active support end date")
That would also allow us to, if the need arises, change the active support end date sometime next year (for whatever reason; let's hope it is not necessary!) without having to open up a discussion about the security end date again ;)
Following the initial discussion, I prepared an RFC that proposes to extend
the support periods for PHP 5.6:https://wiki.php.net/rfc/php56timeline
Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
omissions.Let the discussion continue…
Zeev
-----Original Message-----
From: David Zuelke [mailto:dz@heroku.com]
Sent: Tuesday, December 08, 2015 5:19 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] RFC: PHP 5.6 Support TimelineIt just occurred to me (too late :D sorry Zeev) that it might make sense
to
split this into two RFCs:
- to define the active support end date for 5.6 (e.g. "2016-08-28" or
"2016-
12-02" or "2016-12-31")- to define the security support end date for 5.6, and specify that
relative to
the active support end date only (e.g. "12 months after active support end
date" or "24 months after active support end date")That would also allow us to, if the need arises, change the active support
end date sometime next year (for whatever reason; let's hope it is not
necessary!) without having to open up a discussion about the security end
date again ;)
I think we can do it within the framework of a single RFC - simply make it
clearer in the RFC text that the Security Support term begins when the
Active Support term ends. That way if we want to change the Active Support
term in the future (with another RFC), it won't alter the Security Support
term we agree on here, unless that future RFC explicitly deals with changing
the Security Support term as well.
Makes sense?
Zeev
P.S.: I really hope we can come to a final conclusion as a result of this
RFC, and not have to change it in the future. That's another reason why 1+2
years makes sense - it's far enough in the future to give mostly everyone
enough time to migrate on their own terms, and equally important, for us to
be able to say this publicly, as in "People, we're giving you enough time -
there won't be any additional extensions, plan your migration accordingly".
Am 08.12.2015 um 16:14 schrieb Zeev Suraski:
I prepared an RFC that proposes to extend the support periods for PHP 5.6
Thank you for your work on this RFC, Zeev.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Le 08/12/2015 16:14, Zeev Suraski a écrit :
Following the initial discussion, I prepared an RFC that proposes
to extend the support periods for PHP 5.6:
Thanks for the work.
BTW, to be clear, this is really about "PHP 5 Support Timeline"
(so not about a "minor" version timeline, but really about a "major"
version one, the reason why I will +1 option #1)
Remi.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlZm/hgACgkQYUppBSnxahjrnQCfYz0NYX+RqoPd1rXs4IBm4Tj4
52AAoMTgsnWVtn9pairxWzQHgtvBR7yn
=EPy6
-----END PGP SIGNATURE
BTW, to be clear, this is really about "PHP 5 Support Timeline"
(so not about a "minor" version timeline, but really about a "major"
version one, the reason why I will +1 option #1)
That’ a very good point also raised by Ferenc in his review. I amended it
further and actually changed the title to 'PHP 5 Support Timeline'.
Zeev
Zeev,
Following the initial discussion, I prepared an RFC that proposes to extend
the support periods for PHP 5.6:https://wiki.php.net/rfc/php56timeline
Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
omissions.Let the discussion continue…
I'd prefer it if the RFC took a stance and made a recommendation to
one of the options. That way the discussion could be more guided
around the stance rather than simply generic. And also it makes the
votes easier to understand as it's more of a "yes/no" rather than
multiple options.
Overall, I fall into the 1 year maintenance, 2 year security camp.
That would put 5.6 EOL when 7.3 is out (approximately).
Thanks for putting it together.
Thanks.
-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Tuesday, December 08, 2015 6:09 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] RFC: PHP 5.6 Support TimelineZeev,
Following the initial discussion, I prepared an RFC that proposes to
extend the support periods for PHP 5.6:https://wiki.php.net/rfc/php56timeline
Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any
glaring omissions.Let the discussion continue…
I'd prefer it if the RFC took a stance and made a recommendation to one of
the options.
It does, perhaps not in a strong enough way:
"Further, given the 5.6 -> 7.0 upgrade is more difficult and time
consuming - our recommendation is option #1".
I shuffled things around a bit to make it clearer. Let me know if that
answers your concern.
Overall, I fall into the 1 year maintenance, 2 year security camp.
That would put 5.6 EOL when 7.3 is out (approximately).
Same here!
Zeev
Zeev,
-----Original Message-----
From: Anthony Ferrara [mailto:ircmaxell@gmail.com]
Sent: Tuesday, December 08, 2015 6:09 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] RFC: PHP 5.6 Support TimelineZeev,
Following the initial discussion, I prepared an RFC that proposes to
extend the support periods for PHP 5.6:https://wiki.php.net/rfc/php56timeline
Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any
glaring omissions.Let the discussion continue…
I'd prefer it if the RFC took a stance and made a recommendation to one of
the options.It does, perhaps not in a strong enough way:
"Further, given the 5.6 -> 7.0 upgrade is more difficult and time
consuming - our recommendation is option #1".I shuffled things around a bit to make it clearer. Let me know if that
answers your concern.
Looks much better. Thank you.
I still would rather see one vote (I have a thing against multiple
vote options in general). If it gets denied, then we could do a
different RFC with a different option.
But having the stance being recommended is a good step forward.
Thanks
Anthony
Following the initial discussion, I prepared an RFC that proposes to extend
the support periods for PHP 5.6:https://wiki.php.net/rfc/php56timeline
Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
omissions.Let the discussion continue…
I think you're making the voting too complicated :-) In the case that I
don't want to extend it, I can only pick "no"... but can I still make a
preference for +1 or +2 years? I don't really know...
Better make it a three way choice, where you just tally up the two
"extend please" votes to be over 50%?
cheers,
Derick
See my suggestion to split it into two separate votes ;)
Following the initial discussion, I prepared an RFC that proposes to extend
the support periods for PHP 5.6:https://wiki.php.net/rfc/php56timeline
Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
omissions.Let the discussion continue…
I think you're making the voting too complicated :-) In the case that I
don't want to extend it, I can only pick "no"... but can I still make a
preference for +1 or +2 years? I don't really know...
Better make it a three way choice, where you just tally up the two
"extend please" votes to be over 50%?cheers,
Derick
-----Original Message-----
From: Derick Rethans [mailto:derick@php.net]
Sent: Tuesday, December 08, 2015 6:11 PM
To: Zeev Suraski
Cc: PHP internals
Subject: Re: [PHP-DEV] RFC: PHP 5.6 Support TimelineI think you're making the voting too complicated :-) In the case that I
don't
want to extend it, I can only pick "no"... but can I still make a
preference for
+1 or +2 years? I don't really know...
Technically you could, but you're not supposed to:
Proposed Voting Choices:
- Extend the lifetime of PHP 5.6 yes/no
- -->If you chose to extend it<---, extend it to
- year of Active Support + 2 years of Security Support
- year of Active Support + 1 year of Security Support
Better make it a three way choice, where you just tally up the two "extend
please" votes to be over 50%?
That would effectively be the same thing as it is now, if I'm understanding
correctly. I'm fine with either approaches.
Zeev
Following the initial discussion, I prepared an RFC that proposes to extend
the support periods for PHP 5.6:https://wiki.php.net/rfc/php56timeline
Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
omissions.Let the discussion continue…
Zeev
I still have no idea how to vote, but I'd prefer option 2 the most, option
3 as a backup, and strongly advise against option 1.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
#3 all the way. Extending support only extends the excuse of poor habits
and encourages those habits.
On Tue, Dec 8, 2015 at 2:13 PM, Scott Arciszewski scott@paragonie.com
wrote:
Following the initial discussion, I prepared an RFC that proposes to
extend
the support periods for PHP 5.6:https://wiki.php.net/rfc/php56timeline
Thanks to Ferenc Kovacs and David Zuelke for reviewing it for any glaring
omissions.Let the discussion continue…
Zeev
I still have no idea how to vote, but I'd prefer option 2 the most, option
3 as a backup, and strongly advise against option 1.Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com/
hi,
#3 all the way. Extending support only extends the excuse of poor habits
and encourages those habits.
Same here.
However, if I have to choose something I would like to understand why
all of a sudden December 31 become a valid date. It is unrelated to 7
release date (December 3rd) and has no relevance whatsoever but easier
to remember.
Given this, I would propose to either add, change or update the options with:
-
makes 5.6 deadlines match 7 release date and support lifetime
. Active support until December 3rd 2017,
. Active support extended to one year, end December 3rd, 2017
. And the options for the security support, one or two years -
no change, as stick to what we clearly and openly define in the
lifecycle page (http://php.net/supported-versions.php) and extend
security support to 2 years (ending on 28 Aug 2018)
I had to go with make the dates match with no change, eventually
adding one year for security support as I consider extending the
active support at this stage as a mistake and bad usage of our limited
resources.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Frankly, I think the LTS distros that include PHP 5.6 will be plenty — as
we've seen with 5.3, it has been maintained with back ports long after the
official EOL.
People either understand what they're getting into when making these
choices, or they don't and they don't care anyway.
I'd vote +1 on 2b.
hi,
On Wed, Dec 9, 2015 at 2:51 AM, Adam Howard oldschooldsl@gmail.com
wrote:#3 all the way. Extending support only extends the excuse of poor habits
and encourages those habits.Same here.
However, if I have to choose something I would like to understand why
all of a sudden December 31 become a valid date. It is unrelated to 7
release date (December 3rd) and has no relevance whatsoever but easier
to remember.Given this, I would propose to either add, change or update the options
with:
makes 5.6 deadlines match 7 release date and support lifetime
. Active support until December 3rd 2017,
. Active support extended to one year, end December 3rd, 2017
. And the options for the security support, one or two yearsno change, as stick to what we clearly and openly define in the
lifecycle page (http://php.net/supported-versions.php) and extend
security support to 2 years (ending on 28 Aug 2018)I had to go with make the dates match with no change, eventually
adding one year for security support as I consider extending the
active support at this stage as a mistake and bad usage of our limited
resources.Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi Pierre,
Pierre Joye wrote:
However, if I have to choose something I would like to understand why
all of a sudden December 31 become a valid date. It is unrelated to 7
release date (December 3rd) and has no relevance whatsoever but easier
to remember.
This is a good observation. If we're to sync up 7.0 releases with 5.6,
we should sync up 5.6's EOL with 7.0.
Thanks.
--
Andrea Faulds
http://ajf.me/