Uploading 5.4 RC to unstable (Was: Upcoming transition of php5 to 5.4)

Hi Ondřej,

I'd wait for RC7 in any case, and with some luck it will be the final RC
for 5.4.0.

With my Debian hat on, I would wait for the official release, as to
minimize the noise we'll get in Debian from testing RCs. The recent RCs
all had some major issues fixed/changed in them (which is better to test
with dedicated people than the general users of Debian).

Kaplan

Hi,

I was thinking that it could be a good idea (after current version migrates
to testing) to upload 5.4RCx to unstable to begin work on transition as soon
as possible. RC releases should have stable API(?), so application wise
there's no problem. I'll fill a release critical bug in our BTS, so
the 5.4 version
don't migrate to testing and close it with stable 5.4.0 release.

Ccing PHP internals to let them know and ask if it is a good idea (the 5.4RC
will be probably used by more people when uploaded to Debian unstable, i.e.
it means more testing, but also more bugreports).

O.

---------- Forwarded message ----------
From: Ondřej Surý ondrej@sury.org
Date: Wed, Feb 1, 2012 at 08:40
Subject: Upcoming transition of php5 to 5.4
To: Debian Release debian-release@lists.debian.org

Hi,

this is just a heads up that we would like to ship wheezy with php5 5.4
which is in upstream RC phase now (and in debian-experimental).

It introduce a couple of incompatible changes (for a full list see attached
UPGRADING file), most notably (not listing minor changes and added features):

• default charset is now utf-8
• magic_quotes are deprecated (with warning)
• safe_mode and register_globals was removed
• three new reserved words: callable, insteadof and trait
• multibyte support is now default
• removed syntax (break $var, continue $var)
• sqlite(1) extension was removed (already done in php5.3 in Debian)

I am inclined to let the current php5 in unstable to transition to testing
and then upload next 5.4.0 RC to unstable with transition blocking bug,
so we can start testing existing software as soon as possible.

I also plan to provide "official" backports for Debian squeeze, so people
can come and test new php5.4 before they upgrade to wheezy.

Final note: We already had similar transitions in php (4->5, 5.2->5.3, etc.),
so it's not really a big deal, but it will require some amount of work hence
this email.

Ondrej
P.S.: Please Cc: me as I am not subscribed to the list (but I do check
the web archives).

Ondřej Surý ondrej@sury.org

--
Ondřej Surý <ondrej@sury.org

Ccing PHP internals to let them know and ask if it is a good idea (the 5.4RC
will be probably used by more people when uploaded to Debian unstable, i.e.
it means more testing, but also more bugreports).

Sounds like a good idea to me. This is why we have RCs (and you guys
have unstable IIRC).

Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

Hi,

I was thinking that it could be a good idea (after current version migrates
to testing) to upload 5.4RCx to unstable to begin work on transition as soon
as possible. RC releases should have stable API(?), so application wise
there's no problem. I'll fill a release critical bug in our BTS, so
the 5.4 version
don't migrate to testing and close it with stable 5.4.0 release.

Ccing PHP internals to let them know and ask if it is a good idea (the 5.4RC
will be probably used by more people when uploaded to Debian unstable, i.e.
it means more testing, but also more bugreports).

O.

I support this.

Removal of some legacy features, like these functions:
session_is_registered(), session_register() and session_unregister(), or
removal of .ini stuff like register_globals and register_long_arrays
WILL break applications.

The sooner we have PHP 5.4 in SID, the sooner people will realize
issues, and start fixing.

Anyways, I think we should write few words in -devel@, including
mentioning the above feature removal (or maybe simply showing the URL:
http://www.php.net/releases/NEWS_5_4_0_alpha1.txt, but I don't think
that's enough, insisting on session_register() removal for example,
which must be still widely used, is crucial).

Also, I'd like to know. In PHP 5.3, we had few deprecated functions
(ereg / eregi pops to mind, but also return new as reference). Are these
now totally removed from PHP 5.4, or do they still show with deprecation
warnings?

Thoughts?

Thomas