Hi everyone. I'm trying to plan things for Ubuntu's upcoming 12.04 LTS
release. LTS stands for Long Term Support, and it will be supported by
Canonical for 5 years. Because of this, I really want to ship a version
of PHP that has an is_a() behavior that will be consistent with any
future 5.3.x releases.
We just recently updated to 5.3.8 in the release that will become 12.04
(precise pangolin) somewhat accidentally by following Debian's lead. We
may need to cherry pick the is_a() reversion into this release, but what
I'd rather do is just ship 5.3.9.
The release date is April 26 2012, can anyone tell me if 5.3.9 is expected
by then? Ideally it would be much much earlier than that so users have
time to test. And also can somebody please confirm for me that 5.3.9
will have the is_a() behavior that one would expect all future versions
of PHP 5.3 to have?
Thanks!
The release date is April 26 2012, can anyone tell me if 5.3.9 is
expected
by then?
Yes. 5.3.9 release cycle will start soon. Probably next week. So by
April it is certainly there. I assume even 5.3.10 will be released by
then.
Ideally it would be much much earlier than that so users have
time to test. And also can somebody please confirm for me that 5.3.9
will have theis_a()behavior that one would expect all future
versions of PHP 5.3 to have?
We will not change it from what is in SVN.
johannes
Hi everyone. I'm trying to plan things for Ubuntu's upcoming 12.04 LTS
release. LTS stands for Long Term Support, and it will be supported by
Canonical for 5 years. Because of this, I really want to ship a version
Wouldn't you rather want to include 5.4? 5.3 will no longer be
supported by us shortly after your release.. So for the next 5 years
you will be including something that is already unmaintained?
-Hannes
On Sat, Oct 22, 2011 at 1:03 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:
Hi everyone. I'm trying to plan things for Ubuntu's upcoming 12.04 LTS
release. LTS stands for Long Term Support, and it will be supported by
Canonical for 5 years. Because of this, I really want to ship a versionWouldn't you rather want to include 5.4? 5.3 will no longer be
supported by us shortly after your release.. So for the next 5 years
you will be including something that is already unmaintained?
We did not decide yet that we will stop to support 5.3 right after the
5.4 release. And for one, I think we should continue to suport it
(strict maintenance mode) for a year or two. We can't simply say "heh
look, it is dead" as we got no plan until now. Things are easier for
5.4 and later as we have now a clear release life cycle (as defined in
the RFC).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Pierre Joye wrote:
On Sat, Oct 22, 2011 at 1:03 PM, Hannes Magnusson
hannes.magnusson@gmail.com wrote:Hi everyone. I'm trying to plan things for Ubuntu's upcoming 12.04 LTS
release. LTS stands for Long Term Support, and it will be supported by
Canonical for 5 years. Because of this, I really want to ship a versionWouldn't you rather want to include 5.4? 5.3 will no longer be
supported by us shortly after your release.. So for the next 5 years
you will be including something that is already unmaintained?We did not decide yet that we will stop to support 5.3 right after the
5.4 release. And for one, I think we should continue to suport it
(strict maintenance mode) for a year or two. We can't simply say "heh
look, it is dead" as we got no plan until now. Things are easier for
5.4 and later as we have now a clear release life cycle (as defined in
the RFC).
There is also a lot to be said for going with what is known to be stable for an
LTS release. While hopefully 5.4 will be perfect first time, any problems can't
easily be corrected on a locked down distribution. 5.3 is now 'stable' .. sort
of ... all of the changes are well documented and projects using PHP have had a
good chance to incorporate the PHP5.3 differences. Those projects would not have
time to update to 5.4 before Ubuntu had frozen those inclusions.
While 5.2 is no longer supported, it is still being used on frozen distributions
simply because the projects it is supporting have not upgraded to 5.3. The
various little incompatibilities that have occurred in the 5.3 versions - such
as is_a - are the sort of thing that an LTS freeze aims to avoid ;)
--
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
hi,
There is also a lot to be said for going with what is known to be stable for
an LTS release.
Please do not begin with this discussion again. It is confusing for
the readers and totally unrelated. There is no LTS in the release
process RFC but every release has a fixed lifetime.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
hi,
There is also a lot to be said for going with what is known to be stable for
an LTS release.Please do not begin with this discussion again. It is confusing for
the readers and totally unrelated. There is no LTS in the release
process RFC but every release has a fixed lifetime.
This discussion is about Ubuntu LTS. So 5.4 might be a valid choice for
them.
johannes
2011/10/22 Johannes Schlüter johannes@schlueters.de:
There is also a lot to be said for going with what is known to be stable for
an LTS release.
Please do not begin with this discussion again. It is confusing for
the readers and totally unrelated. There is no LTS in the release
process RFC but every release has a fixed lifetime.
This discussion is about Ubuntu LTS. So 5.4 might be a valid choice for
them.
If we can get a 5.4 they're reasonably comfortable with out in time,
I'd argue very strongly for its inclusion. We've already got 5.4 in
beta. I don't think it's crazy to think we'd have a 5.4.0 in plenty of
time to let them do plenty of testing.
We're talking about locking a major vendor into a major version for
-five- years, not Ubuntu's usual three. 5.4 will give them a head
start versus what would otherwise be starting already out of date - by
the time Ubuntu 12.04 is officially released, they'd be behind with
5.3. My understanding of LTS is not that it's a total freeze, but that
they support it for bug fix updates and such. So we could expect 5.4.x
releases to get in (or be backported/cherry-picked) if they had
important fixes, as long as we don't have another is_a() snafu.
-- Gwynne
Johannes Schlüter wrote:
There is also a lot to be said for going with what is known to be stable for
an LTS release.
Please do not begin with this discussion again. It is confusing for
the readers and totally unrelated. There is no LTS in the release
process RFC but every release has a fixed lifetime.
This discussion is about Ubuntu LTS. So 5.4 might be a valid choice for
them.
Correct, but Ubuntu distribution includes a number of PHP powered applications
and extensions, and they would be stable on PHP5.3 so putting PHP5.4 in instead
would be a major mistake. Clint needs to bare that in mind when making any decision?
--
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
Am 22.10.2011 17:36, schrieb Lester Caine:
Johannes Schlüter wrote:
There is also a lot to be said for going with what is known to be stable for
an LTS release.
Please do not begin with this discussion again. It is confusing for
the readers and totally unrelated. There is no LTS in the release
process RFC but every release has a fixed lifetime.
This discussion is about Ubuntu LTS. So 5.4 might be a valid choice for
them.Correct, but Ubuntu distribution includes a number of PHP powered applications and extensions, and they would be
stable on PHP5.3 so putting PHP5.4 in instead would be a major mistake. Clint needs to bare that in mind when
making any decision?
you missed that here is a disuccsion of a FUTURE VERSION of ubuntu
tell us WAHT applications do not run with 5.4
until you can not please call it not a "major mistake"
a major mistake is that distributiins hanging years behind current
php versions and so php-developers of widely used applications
can not use new features and upgrade their development and the
result of this is "would be stable with an old version"
so you are missing the root causes of problems
if ubunto will release a new major version with 5.3 instead
5.4 ALL application developers must use 5.3 the next five years
because this decision
Excerpts from Hannes Magnusson's message of Sat Oct 22 04:03:50 -0700 2011:
Hi everyone. I'm trying to plan things for Ubuntu's upcoming 12.04 LTS
release. LTS stands for Long Term Support, and it will be supported by
Canonical for 5 years. Because of this, I really want to ship a versionWouldn't you rather want to include 5.4? 5.3 will no longer be
supported by us shortly after your release.. So for the next 5 years
you will be including something that is already unmaintained?
I appreciate the sentiments of all who have weighed in on this, and I
do want to make sure that we are paying attention to the greater PHP
community's needs, not just Ubuntu's users. Shipping really old PHP
versions is definitely not what we want to do.
However, we do need to be able to support the release with updates.
While 5.4 would probably mean more of those updates would be simple cherry
picks from 5.4, it also means there would likely be a lot more of them,
since 5.4.0 will undoubtedly be a more aggressive release than 5.3.9, and
like any ".0" release, it just won't have the exposure that 5.3.x has had.
Also, we have 105 PHP applications in Ubuntu, 2 of which are in our "main"
component (ganglia and nagios), which means they are supported by our
security team and developers for the entire lifecycle of a release. Its
not likely that we would be able to test all 105 of them with PHP 5.4
before the release date, which may mean some of them will be quite broken,
and also require stable release updates to fix.
Now, all of that said, I would love to have 5.4 as the version in 12.04.
Since 103 of the 105 apps are "community" supported, that means we'd
need a large community effort to make sure this is doable.
Here's what would need to happen for 12.04 to ship with 5.4 instead of 5.3:
- PHP needs to make a commitment to release very soon. Beta is fine
for the first month or so of the cycle, but not more. - App developers need to commit to testing their apps on the dev release
of Ubuntu. If people are interested, I'd be happy to set up a jenkins
instance somewhere and give people write access to a bzr/svn/git tree
of tests to run daily on the dev release. - We would need buy in from the rest of the server interested folks
and the Ubuntu security team. The right time to discuss that is at the
Ubuntu Developer Summit, which is coming up in Orlando, FL, US, just a
week from Monday (starts Oct 31). - We need it at least in Debian experimental, preferrably in
Debian unstable. I have not discussed this at all with the Debian PHP
maintainers, so this is a big unknown. I've cc'd them for their comment.
I do see that 5.4.0 beta is in experimental as of yesterday, so I suspect
this will happen naturally.
So, I've registered a blueprint for UDS here:
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54
There's no guarantee we will be able to fit it in, so make sure to
subscribe to it if you are interested in this topic.
If any of you are interested in joining us virtually (or physically!)
You can go here:
https://launchpad.net/sprints/uds-p
And register, then find it on the schedule at http://summit.ubuntu.com
If you register for UDS-P with your available times, and subscribe
yourself as "essential" for the blueprint, then the scheduler for the
summit will make a best effort to put the session during the times you
are available.
I appreciate the sentiments of all who have weighed in on this, and I
do want to make sure that we are paying attention to the greater PHP
community's needs, not just Ubuntu's users. Shipping really old PHP
versions is definitely not what we want to do.
At the same time, in 5 years I don't think 5.4 will be that much "newer"
feeling than a late 5.3 release, both will likely not be supported by
the PHP authors, and people will complain that it's out of date no
matter what. So imo it's ultimately a matter of which version is more
stable and can be better supported by the package maintainers and security
teams in question. I don't yet have an opinion on that, but would defer
to other members of the debian team if they did.
And note that just because it's the default/supported version does not mean
that those distro-users are left up the creek without a paddle. Both ubuntu
and debian provide multiple avenues for stable/LTS users to get newer software
installed from backport/ppa type repositories, and they're also free to
install from source if those packages do not meet their needs.
- We need it at least in Debian experimental, preferrably in
Debian unstable. I have not discussed this at all with the Debian PHP
maintainers, so this is a big unknown. I've cc'd them for their comment.
I do see that 5.4.0 beta is in experimental as of yesterday, so I suspect
this will happen naturally.
I'm not sure we have a solid plan/timeline on this, but FYI if you sync'd the
last 5.3.x version from us the source package was slightly fubar'd (somehow
got turned into a native package). We'll probably fix it with an epoch'd
upload or just wait until 5.4 is ready enough for unstable, but I don't think
we've decided on which yet.
sean
Just my two cents,
Most likely someone that has a system that they expect to last for five years is going to set it up and forget about it. So they probably don't care that it's up to date. They just want it to work.
If not they'll likely either compile their own php or be updating their system long before five years is up.
Sent from my iPhone
I appreciate the sentiments of all who have weighed in on this, and I
do want to make sure that we are paying attention to the greater PHP
community's needs, not just Ubuntu's users. Shipping really old PHP
versions is definitely not what we want to do.At the same time, in 5 years I don't think 5.4 will be that much "newer"
feeling than a late 5.3 release, both will likely not be supported by
the PHP authors, and people will complain that it's out of date no
matter what. So imo it's ultimately a matter of which version is more
stable and can be better supported by the package maintainers and security
teams in question. I don't yet have an opinion on that, but would defer
to other members of the debian team if they did.And note that just because it's the default/supported version does not mean
that those distro-users are left up the creek without a paddle. Both ubuntu
and debian provide multiple avenues for stable/LTS users to get newer software
installed from backport/ppa type repositories, and they're also free to
install from source if those packages do not meet their needs.
- We need it at least in Debian experimental, preferrably in
Debian unstable. I have not discussed this at all with the Debian PHP
maintainers, so this is a big unknown. I've cc'd them for their comment.
I do see that 5.4.0 beta is in experimental as of yesterday, so I suspect
this will happen naturally.I'm not sure we have a solid plan/timeline on this, but FYI if you sync'd the
last 5.3.x version from us the source package was slightly fubar'd (somehow
got turned into a native package). We'll probably fix it with an epoch'd
upload or just wait until 5.4 is ready enough for unstable, but I don't think
we've decided on which yet.sean
Hi,
I have always disliked the lack of modern packages on Debian/Ubuntu distros,
I feel like minor are misused as major versions, with an exaggerated fear to
upgrade. It's like building web sites for IE6 because people are not allowed
to upgrade to IE9, very frustrating for developers and hard to explain to
stakeholders. (OT: so I welcomed Chrome/FF choice to bump major versions
very frequently).
Why can Ubuntu only support 5.3.x and not simply 5.x ? As far as I can see
BC will be guaranteed, PHP maintainers are really committed to it, and only
a new major version would be so problematic as many suggest.
As a user, I would really encourage to include the latest stable 5.x and
provide to the community all the available 5.x upgrade during the next 5
years (5.4, 5.5 etc). Those 105 php apps should be maintained or removed,
not used as an excuse to slow down the community.
Then, if a PHP 6 will ever be released, then someone will rightly wonder
"should we include PHP 6 in the next LST ?"
- my .02 -
Just my two cents,
Most likely someone that has a system that they expect to last for five
years is going to set it up and forget about it. So they probably don't care
that it's up to date. They just want it to work.If not they'll likely either compile their own php or be updating their
system long before five years is up.Sent from my iPhone
I appreciate the sentiments of all who have weighed in on this, and I
do want to make sure that we are paying attention to the greater PHP
community's needs, not just Ubuntu's users. Shipping really old PHP
versions is definitely not what we want to do.At the same time, in 5 years I don't think 5.4 will be that much "newer"
feeling than a late 5.3 release, both will likely not be supported by
the PHP authors, and people will complain that it's out of date no
matter what. So imo it's ultimately a matter of which version is more
stable and can be better supported by the package maintainers and
security
teams in question. I don't yet have an opinion on that, but would defer
to other members of the debian team if they did.And note that just because it's the default/supported version does not
mean
that those distro-users are left up the creek without a paddle. Both
ubuntu
and debian provide multiple avenues for stable/LTS users to get newer
software
installed from backport/ppa type repositories, and they're also free to
install from source if those packages do not meet their needs.
- We need it at least in Debian experimental, preferrably in
Debian unstable. I have not discussed this at all with the Debian PHP
maintainers, so this is a big unknown. I've cc'd them for their comment.
I do see that 5.4.0 beta is in experimental as of yesterday, so I
suspect
this will happen naturally.I'm not sure we have a solid plan/timeline on this, but FYI if you sync'd
the
last 5.3.x version from us the source package was slightly fubar'd
(somehow
got turned into a native package). We'll probably fix it with an epoch'd
upload or just wait until 5.4 is ready enough for unstable, but I don't
think
we've decided on which yet.sean
Am 25.10.2011 00:18, schrieb devis@lucato.it:
As a user, I would really encourage to include the latest stable 5.x and
provide to the community all the available 5.x upgrade during the next 5
years (5.4, 5.5 etc). Those 105 php apps should be maintained or removed,
not used as an excuse to slow down the community
the problem is that most php code out there is useless crap
i maintain some hundret thousands line of codes since 10 years
and did every php-upgrade even 4.x to 5.x without having more
than a handful lines to optimize / replace
the reason is that most developers out there too stupid to use
E_ALL | E_STRICT on their machines and do not see any warnings
while we have this error-level actibe on some hundret domains
all scripts /applications have to run with this settings or
fixed or removed from our servers - and would most developers
act the same way you could easily upgrade to each php-version
so crappy applications have to be removed from the distributions
to prevent the neagtive impact of "never use any new features
because most servers out there are for years outdated"
this is possible over years in production environment if
you have not to rely on broken apps:
php-5.3.8-21.fc14.rh.20110823.x86_64
mysql-5.5.17-3.fc14.rh.20111022.x86_64
postfix-2.8.6-3.fc14.rh.20111024.x86_64
Excerpts from devis's message of Mon Oct 24 15:18:14 -0700 2011:
Hi,
I have always disliked the lack of modern packages on Debian/Ubuntu distros,
I feel like minor are misused as major versions, with an exaggerated fear to
upgrade. It's like building web sites for IE6 because people are not allowed
to upgrade to IE9, very frustrating for developers and hard to explain to
stakeholders. (OT: so I welcomed Chrome/FF choice to bump major versions
very frequently).Why can Ubuntu only support 5.3.x and not simply 5.x ? As far as I can see
BC will be guaranteed, PHP maintainers are really committed to it, and only
a new major version would be so problematic as many suggest.As a user, I would really encourage to include the latest stable 5.x and
provide to the community all the available 5.x upgrade during the next 5
years (5.4, 5.5 etc). Those 105 php apps should be maintained or removed,
not used as an excuse to slow down the community.
devis, Firefox and Chrome are "leaf" packages. They can bump versions
and they only affect one package, themselves. This allows testing to be
simple and definitive.
PHP supports not only the 105 apps in the Ubuntu archive, but thousands
upon thousands of PHP applications which people write to run on top
of Ubuntu.
By freezing around a single version, and emphatically reviewing each
update to ensure it does not introduce any changes in behavior (even
positive changes!) without a clear justification (fixing a critical
bug for instance), users can be assured that the app they write for any
given release of Ubuntu will continue to function for the life of that
release.
We actually do have a "micro release exception" process which we have
in place for a few upstreams:
https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
PHP5 isn't actually that far off from the requirements there, just need
to enable the regression tests in the build and have them all pass. As
I understand it, PHP 5.4 will have that, so one more positive for that.
Note that we also have the ubuntu-backports project which can be used
to obtain newer versions in the older release. There is a requirement,
however, that all dependent packages are smoke tested with each backport,
so somebody would have to automate testing all of the PHP applications
in Ubuntu before backports was a viable option.
Hi,
I have always disliked the lack of modern packages on Debian/Ubuntu
distros, I feel like minor are misused as major versions, with an
exaggerated fear to upgrade.
There was quite some changes with some resulting issue when switching
Squeeze from 5.2 to 5.3, for example having a deprecation notice warning
about return of a reference, or the removal of some function. This did
break things, especially when dealing with XML or other parsable outputs
(I remember fixing a bunch of them last year before Squeeze was out, and
there's still some remaining to fix).
It's like building web sites for IE6
because people are not allowed to upgrade to IE9, very frustrating for
developers and hard to explain to stakeholders.
This has nothing to do with it. IE6 isn't maintained anymore, and we
don't have the sources to backport security issues. And it's not about
not being allowed to upgrade (you are free to upgrade to the version of
php currently in experimental for example), it's about supporting a
given version for the life of a distribution, because that's what we do,
which is very different. That's a very bad comparison, IMHO.
(OT: so I welcomed
Chrome/FF choice to bump major versions very frequently).
I don't. There was no major changes between FF 5, 6 or 7, and they've
dropped support for 5 and 6 so fast. That's not being responsible for
what they release, and not being nice at all for downstream
distributions and their users. Since I am using FF7, a bunch of things
have broke (like in some case, my mplayer plugin), and I have no way to
fix it. I would have happily keep FF5 or 6 which were perfect for me,
but no choice, they aren't supported, and have security issues. So I'm
stuck. This is the kind of situation we want to avoid here!
Why can Ubuntu only support 5.3.x and not simply 5.x ?
Because 5.2 and 5.3 were different, and probably 5.4 will also bring
changes. The difference isn't only in the version, but also on the
behavior, which needs to be addressed.
As far as I can
see BC will be guaranteed, PHP maintainers are really committed to it,
and only a new major version would be so problematic as many suggest.
When you say "BC", do you mean "Backward Compatibility"? Well, see
above, it might be compatible, but there are still issues!!!
As a user, I would really encourage to include the latest stable 5.x and
provide to the community all the available 5.x upgrade during the next 5
years (5.4, 5.5 etc).
No. We aren't doing releases like CentOS does, and which creates lots of
issues. If you want to change from one version to another, you got to be
the one deciding to do it, a particular version of a distribution
shouldn't never force you to do it, and there should be zero
behavior change if possible.
Those 105 php apps should be maintained or
removed, not used as an excuse to slow down the community.
They are maintained or removed, but you see, checking for each of them
isn't something that can be done in few days: it takes time, and you got
to give each maintainer enough time for it.
Then, if a PHP 6 will ever be released, then someone will rightly wonder
"should we include PHP 6 in the next LST ?"
Most probably, both PHP 5.x and 6.x will be maintained for a while at
the same time, to give people enough time to transition to it, exactly
like what happened when switching from 4 to 5. That is, of course, if we
have enough human time to work on this. I hope that upstream PHP
maintainers will also maintain 5.x for a while when they will start
advising to switch to 6.
Thomas Goirand (zigo)
Thomas Goirand wrote:
There was quite some changes with some resulting issue when switching
Squeeze from 5.2 to 5.3, for example having a deprecation notice warning
about return of a reference, or the removal of some function. Thisdid
break things, especially when dealing with XML or other parsable outputs
(I remember fixing a bunch of them last year before Squeeze was out, and
there's still some remaining to fix).
This was the point I was trying to make. We have some very useful packages that
as yet have not been 'upgraded' to 5.3 due to lack of time. Yes they run, but
the deprecated warnings and the like ARE a problem in themselves, and working
through code simply to clear warnings, and still maintain BC for people using
5.2 for other reasons is yet another distraction.
I am expecting the same types of problem from 5.3 to 5.4 and already have
problems because test scripts will no longer run on the 5.2 test machine ....
--
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
hi Clint,
I appreciate the sentiments of all who have weighed in on this, and I
do want to make sure that we are paying attention to the greater PHP
community's needs, not just Ubuntu's users. Shipping really old PHP
versions is definitely not what we want to do.
Well, PHP 5.3 is the current stable, it is not like it is that old (3
years already tho').
However, we do need to be able to support the release with updates.
While 5.4 would probably mean more of those updates would be simple cherry
picks from 5.4, it also means there would likely be a lot more of them,
since 5.4.0 will undoubtedly be a more aggressive release than 5.3.9, and
like any ".0" release, it just won't have the exposure that 5.3.x has had.
Well, things may change as we have now some stricter rules when it
comes to BC breaks and related areas.
Also, we have 105 PHP applications in Ubuntu, 2 of which are in our "main"
component (ganglia and nagios), which means they are supported by our
security team and developers for the entire lifecycle of a release. Its
not likely that we would be able to test all 105 of them with PHP 5.4
before the release date, which may mean some of them will be quite broken,
and also require stable release updates to fix.
If you can list the ones which have unit tests, then we should
definitively do test them now and here using php's snapshots. If your
team could get this list shortly, we can them share resources to setup
the automating testing. We already do that in our labs for a couple of
applications and php's unit tests. Frameworks are coming too.
Now, all of that said, I would love to have 5.4 as the version in 12.04.
Since 103 of the 105 apps are "community" supported, that means we'd
need a large community effort to make sure this is doable.
Yes, and maybe the upstream teams of the respective apps would be
willing to help. But it is a huge communication effort and any help is
welcome. I'm working with some apps and mainly with frameworks lately
(symfony being the most active here).
Here's what would need to happen for 12.04 to ship with 5.4 instead of 5.3:
- PHP needs to make a commitment to release very soon. Beta is fine
for the first month or so of the cycle, but not more.
I would suggest to read the following RFC and todos:
https://wiki.php.net/rfc/releaseprocess
https://wiki.php.net/todo/php54
I would not expect to have 5.4.0 final out before end of december or
early next year. The rest is defined by the RFC. I think we can expect
more frequent releases than what we used to do, but smaller, which is
actually better.
- App developers need to commit to testing their apps on the dev release
of Ubuntu. If people are interested, I'd be happy to set up a jenkins
instance somewhere and give people write access to a bzr/svn/git tree
of tests to run daily on the dev release.
That's something we can try to work together, by contacting the
respective teams and get tests infrastructure together. The key is to
get the testing results as frequently as possible.
Thanks for coming to us to discuss this, it is very appreciated!
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Excerpts from Clint Byrum's message of Sun Oct 23 18:36:04 -0400 2011:
So, I've registered a blueprint for UDS here:
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54
There's no guarantee we will be able to fit it in, so make sure to
subscribe to it if you are interested in this topic.If any of you are interested in joining us virtually (or physically!)
You can go here:https://launchpad.net/sprints/uds-p
And register, then find it on the schedule at http://summit.ubuntu.com
If you register for UDS-P with your available times, and subscribe
yourself as "essential" for the blueprint, then the scheduler for the
summit will make a best effort to put the session during the times you
are available.
Thanks to those of you who subscribed or attended virtually.
We decided to defer this decision to January based on the status of 5.4.0.
Its most likely we'll follow Debian's lead, so if Debian testing has
5.4.0 at that time, and we get a sufficient amount of testing, we will
go ahead and update to 5.4.0.
We'll also be setting up a PPA with 5.4.0 and all extensions compiled
against it so users can try out their applications on "precise" with 5.4.0
before we actually do the transition.
Please watch the blueprint if you are interested:
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54