# Towards 5.3 RC

- Thread: https://externals.io/message/43292
- Original archive: https://news-web.php.net/php.internals/43292
- Started by johannes@php.net on 2009-03-10T16:04:23+00:00
- Messages: 7
- 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

---

## #43292 — johannes@php.net — 2009-03-10T16:04:23+00:00

URL: https://externals.io/message/43292#43292

Hi,

I wrote a mail last Friday about this but it seems like it got lost. I
wanted to go RC on Thursday, as this now would be a rather short-time
announcement (while quite a few devs already knew) this plan has changed
by a week:


PHP 5.3.0 RC 1 is now scheduled for Thursday 2009/03/19.


This means we'll enter the pre-build commit-freeze for build fixes only
on Wednesday 2009/03/18.

As there were some misunderstandings what "build fixes only" means
before here my reading of that: Build fixes are changes to source files
(.c, .h, .re, ...) which fix compilation of the code on a supported
platform (and don't break it for others). Build fixes also include fixes
for tests, as long as the diff makes the changes clear (a complete
rewrite of a test isn't clear, a change from  %a to %s or additional
cleanup is), as well as fixes to README files and similar. If in doubt
please try to commit your stuff sooner or ask :-)


That said: On the wiki is a list of open items
http://wiki.php.net/todo/php53#next_release_beta2rc1

Item 1 is, of course, the big one: Bug fixing. Most of the ones filed
against 5.3 are assigned. If you have bugs assigned to yourself but
won't be able to fix it soonish please un-assign it with a comment -
especially if you consider it critical so somebody else can take over.
There are also many bugs filed against 5.2 (or older versions) while I
won't consider most of the release critical for 5.3.

Some other parts of that todo list are fixed (like the UPGRADING guide)
or just need to be committed (new ini files) Please take a look.


Other than that I have two main concerns:

- Unknown bugs in Namespaces/Closures/... which will only be found in
  real life testing, not sure how to get them properly tested.

- Accidental BC breaks, for instance in edge cases while changing to
  zend_parse_parameters. There were some fixes already, but more
  testing with real applications should still help (what I'm doing on my
  private server in a "production" environment for instance) So please
  test your own PHP code as well as apps you use on 5.3. Thanks.


So devs please check over open bugs and open todo items.

And everybody please help by testing (and I'm sure the doc team welcomes
assistance). I also welcome feedback (using a mail directly to me for
instance) if you tested some bigger apps (bugs should go to the bug
tracker, of course) since feedback like "my 1M loc app works like a
charm" helps me, too.

Thanks so much,
johannes

---

## #43294 — Stanislav Malyshev — 2009-03-10T17:13:00+00:00

URL: https://externals.io/message/43292#43294 · In reply to: #43292

Hi!

> That said: On the wiki is a list of open items
> http://wiki.php.net/todo/php53#next_release_beta2rc1

I don't think #21 there is a bug - AFAIK client of get_class_name is 
supposed to free it - which happens automatically if this is assigned to 
zval, but otherwise it should be handled by calling code.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com

---

## #43300 — Greg Beaver — 2009-03-10T20:52:17+00:00

URL: https://externals.io/message/43292#43300 · In reply to: #43294

Stanislav Malyshev wrote:
> Hi!
> 
> > […]
> 
> I don't think #21 there is a bug - AFAIK client of get_class_name is
> supposed to free it - which happens automatically if this is assigned to
> zval, but otherwise it should be handled by calling code.

This is likely a problem in xdebug (CVS) which I was running, which of
course is also not yet fully ready for PHP 5.3, so I think #21 can be
removed.

Greg

---

## #43379 — Lukas Kahwe Smith — 2009-03-17T09:59:12+00:00

URL: https://externals.io/message/43292#43379 · In reply to: #43292

> Hi,
>
> I wrote a mail last Friday about this but it seems like it got lost. I
> wanted to go RC on Thursday, as this now would be a rather short-time
> announcement (while quite a few devs already knew) this plan has  
> changed
> by a week:
>
>
> PHP 5.3.0 RC 1 is now scheduled for Thursday 2009/03/19.
>
>
> This means we'll enter the pre-build commit-freeze for build fixes  
> only
> on Wednesday 2009/03/18.

Just a reminder. This means today is the day to get your fixes in. Is  
anyone looking over Matt's patches?

Also on the wiki are several open todo items:
http://wiki.php.net/todo/php53#rc1

Please let me know if any items on there are already done.
Also let Johannes and myself know of any show stoppers that will not  
get completed today.
Remember this is an RC, so we should be quite serious about the  
quality we are releasing.

This is the time for bug fixes and _not_ for features. I know there is  
a certain tendency to put features first, since important open bug  
fixes delay a release, while feature additions at this point will not.  
I ask everybody to pay "fair" and focus on getting PHP 5.3 out the  
door, rather than rushing features in now, that take away the focus  
from bug fixing and worse yet could add new bugs.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

---

## #43388 — Lukas Kahwe Smith — 2009-03-18T10:06:45+00:00

URL: https://externals.io/message/43292#43388 · In reply to: #43379

>
> 
>
> > […]
>
> Just a reminder. This means today is the day to get your fixes in.  
> Is anyone looking over Matt's patches?
>
> Also on the wiki are several open todo items:
> http://wiki.php.net/todo/php53#rc1
>
> Please let me know if any items on there are already done.
> Also let Johannes and myself know of any show stoppers that will not  
> get completed today.
> Remember this is an RC, so we should be quite serious about the  
> quality we are releasing.
>
> This is the time for bug fixes and _not_ for features. I know there  
> is a certain tendency to put features first, since important open  
> bug fixes delay a release, while feature additions at this point  
> will not. I ask everybody to pay "fair" and focus on getting PHP 5.3  
> out the door, rather than rushing features in now, that take away  
> the focus from bug fixing and worse yet could add new bugs.


Ok, since there is too much last minute stuff going on and we are  
aiming for a release quality RC1, we have decided to move the release  
date to next Tuesday, the 24th.

Bug fixing until this Friday. Any other bug fixing over the weekend  
needs the nod of one of the RMs. Build fixing Monday. Release Tuesday.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

---

## #43389 — Lukas Kahwe Smith — 2009-03-18T13:55:04+00:00

URL: https://externals.io/message/43292#43389 · In reply to: #43388

>
> 
>
> > […]
>
>
> Ok, since there is too much last minute stuff going on and we are  
> aiming for a release quality RC1, we have decided to move the  
> release date to next Tuesday, the 24th.
>
> Bug fixing until this Friday. Any other bug fixing over the weekend  
> needs the nod of one of the RMs. Build fixing Monday. Release Tuesday.


At the request of Pierre, I am tightening the commit window.
Please finish all bug fix commits by Thursday.
If there are any last minute discoveries, you can ask Johannes and  
myself to be allowed to commit on Friday. The later in the day the  
request comes, the less likely we are to approve the commit.

Anything after that (including commits to the test suite) will need to  
be reverted unless its a build fix. Please do not waste time doing  
reverts. Release candidates need proper QAing ahead of time. In the  
future we will try to stick with Thursday releases with a commit  
freeze starting the Tuesday before, to give two full week days of  
build fixing.

As such it would be appreciated if people can spend some time on the  
weekend to do as much build fixing as possible to ensure that we can  
get done on Monday in order to release on Tuesday.

regards,
Lukas Kahwe Smith
mls@pooteeweet.org

---

## #43390 — Pierre Joye — 2009-03-18T14:03:39+00:00

URL: https://externals.io/message/43292#43390 · In reply to: #43389

> At the request of Pierre, I am tightening the commit window.

It is a special wish from, it is common sense. The changes applied
today require real testing and validations, they are likely to have
impact on many platforms.

> Please finish all bug fix commits by Thursday.
> If there are any last minute discoveries, you can ask Johannes and myself to
> be allowed to commit on Friday. The later in the day the request comes, the
> less likely we are to approve the commit.
>
> Anything after that (including commits to the test suite) will need to be
> reverted unless its a build fix. Please do not waste time doing reverts.
> Release candidates need proper QAing ahead of time. In the future we will
> try to stick with Thursday releases with a commit freeze starting the
> Tuesday before, to give two full week days of build fixing.

Thanks, that will be the only way to actually be able to valid a given
release (be beta, rc or final). It will also be nicer to the
developers actually having other things to do on the Sunday night than
fixing what other broke during the weekend. Weekend should not be
counted as "productive" day, they are bonuses if some can or want to
work during the weekend, but including them in any kind of time plan
for a release cannot work.


Cheers,
--
Pierre

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