PHP 7.0.1 scheduling View as Markdown

Hi Ferenc,

-----Original Message-----
From: tyra3l@gmail.com [mailto:tyra3l@gmail.com] On Behalf Of Ferenc
Kovacs
Sent: Tuesday, December 8, 2015 2:41 PM
To: Julien Pauli jpauli@php.net
Cc: Remi Collet remi@php.net; PHP Internals internals@lists.php.net;
Anatol Belsky ab@php.net; Stanislav Malyshev stas@php.net
Subject: Re: [PHP-DEV] Re: PHP 7.0.1 scheduling

Le 08/12/2015 12:36, Anatol Belski a écrit :

Yeah, particularly our release schedule collides with many holidays
this year. For a security release a holiday time is obviously very bad.

+1

Our Release Process state:

    " At least one release per month, more at wish "

Perhaps we should consider new release on

    " 1st thursday of the month "

(It seems every year, Christmas is end of month ;)

Yep, end of year has always collided with our release cycle.

Perhaps we should change this latter as proposed by Remi ?

Also, we had another idea.

Why not use RC2 as a chance for some security patches to get tested ?
If we have a RC2 (which is not bad IMO, we have a time slice here at
end of 2015 that enables us to release an RC2) , we then could merge
into this one some well-selected security patches, f.e, some that are
low classified , aka that can't get trigerred remotely by user
payload.

What you think ?

CCing Stas as well, as he got many experience in security.

Julien.P

we are just iterating by two weeks which makes the monthly release not
monthly but every 28 days, which is fine but that also means that sometimes the
release dates are not always at the same date on each month (stating the
obvious).
I think that there is no better alternative, we just have to handle the exceptional
cases.
As we seem to have security fixes (and unfortunatelly at least one of those were
directly pushed by laruance so now it is public information) maybe we should
release it one week earlier (cutting the RC period one week shorter) instead of
delaying it until january?
Yeah, that works for 7.0 alone in any case. If it's about 7.0.1 only, it were

• 7.0.1RC1 on 10th December
• 7.0.1 final on 17th December
• 7.0.2RC1 on 24th or 31st
• 7.0.2 final next year together with 5.5.31 and 5.6.17

Probably it could make sense, 7.0.1 in any case on 17th then - what was disclosed was only one patch and relevant for 7.0 only. 17th is also holiday free, hopefully :) If PHP 5 branches could not be so far, we should indeed get 7.0.1 out this year, and we would sync 5 and 7 release dates starting with 7.0.2 and next year. How does it sound?

Regards

Anatol

Hi!

Why not use RC2 as a chance for some security patches to get tested ?
If we have a RC2 (which is not bad IMO, we have a time slice here at
end of 2015 that enables us to release an RC2) , we then could merge
into this one some well-selected security patches, f.e, some that are
*low* classified , aka that can't get trigerred remotely by user
payload.

Generally, if we publish security patch we should release ASAP, as
having public unpatched security issue is bad. Fortunately, the issue
disclosed is not that bad, I'd even doubt it is security issue per se,
as I see no real way to trigger it without code access (it may be I miss
something though).

Accelerating the schedule is OK with me (as is keeping the current one,
too) but please do not forget to merge pending patches (or please tell
me when you want me to merge them).

Thanks,

Stas Malyshev
smalyshev@gmail.com