Greetings geeks
With the recent additions to 5.4, aren't we getting closer to have a
public alpha release, or just a development test as we have many great
additions and changes to the current trunk or atleast set up some sort
of roadmap for what we all like to have in 5.4, or be that 6.0 as
thats yet another thing we should get settled soonish.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
hi,
Huge -1 here.
We are light years away to even be able to define what will be
php-next. Let discuss that September, at the soonest.
Cheers,
Greetings geeks
With the recent additions to 5.4, aren't we getting closer to have a
public alpha release, or just a development test as we have many great
additions and changes to the current trunk or atleast set up some sort
of roadmap for what we all like to have in 5.4, or be that 6.0 as
thats yet another thing we should get settled soonish.--
regards,Kalle Sommer Nielsen
kalle@php.net--
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
With the recent additions to 5.4, aren't we getting closer to have a
public alpha release, or just a development test as we have many great
additions and changes to the current trunk or atleast set up some sort
of roadmap for what we all like to have in 5.4, or be that 6.0 as
thats yet another thing we should get settled soonish.Huge -1 here.
We are light years away to even be able to define what will be
php-next. Let discuss that September, at the soonest.
I could not disagree more. I think one of the key lessons we should
have learned out of the whole 6.0 saga was that "release early,
release often" is a good thing, and I don't see much on the RFC list
or that's been discussed recently on Internals that's going to be
significantly advanced if we leave even discussing it another month or
more. I think it's time to make a few decisions on what's in and
what's out and move on.
Trunk doesn't seem to be in a bad state, all told, so I'd love to see
a 5.3+δ alpha next month (presumably towards the end of it) — that
doesn't imply a feature freeze, or remove the possibility to change
things later, but it does tell developers that we're pretty serious
about what's in trunk, and that we want people to start playing with
some of the new features like traits to see how it effects them and
start reporting bugs.
Bear in mind, too, that even with a September alpha, we'd still be
looking at a release early next year at the earliest. Even on the
quickest timeline I could imagine — a couple of alphas, maybe a first
beta on the run down to Christmas, another beta or two early next
year, then some RCs — I can't see a stable release until autumn (OK,
spring for most of you: March-May) next year, which would be the best
part of two years after 5.3.0. Remember, that's assuming we move fast,
and history's against us there. :)
Adam, who looks forward to getting flamed on IRC later for writing
another long screed. :)
I could not disagree more. I think one of the key lessons we should
have learned out of the whole 6.0 saga was that "release early,
release often" is a good thing
I will no support the release of trunk overly actively as long as the
"type hints" are as they are but on a general note:
Yes. Release early, release often is a good thing. What I'd also like is
to have a Ubuntu-like support model. Where we have one LTS (long term
supported) version (now for instance 5.3) which will get bug fixes for
quite some time and an "early access" version (5.4) which will receive
updates until the next "early access" (5.5) is there.
Reasons:
* Give people early access to features
* Motivate developers as their additions are in a reachable future
* Give users the chance to stay on the LTS version without having
to do the full update on every release
* Reduce the number of changes in "bugfix" releases
the whole idea in ASCII art:
Version Time ->
5.3 ***********+++++
5.4 |
5.5 || *****
5.6 || | *****
6.0 || | | ****************
6.1 || | | | *****
|| | | | |
|| | | | ^ Release date 6.1.0
|| | | ^ Release 6.0.0, 5.3 goes to extended support (security only)
|| | ^ Release 5.6.0, 5.3 stays in support, 5.5 EOL
|| ^ Release 5.5.0, 5.3 stays in support, 5.4 EOL
|^ Release 5.4.0, 5.3 stays in support
^ now
So we'd always have three branches, while two only receive bug fixes,
plus one branch for the next milestone.
johannes
Am 10.08.2010 10:45, schrieb Johannes Schlüter:
So we'd always have three branches, while two only receive bug fixes,
plus one branch for the next milestone.
+1
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Sebastian Bergmann wrote:
So we'd always have three branches, while two only receive bug fixes,
plus one branch for the next milestone.
+1
And currently 5.2.x is still the preferred base as there is still a lot of third
party stuff that has to make the transition to 5.3.x ... Pushing new stuff
through is all very well, but some core code bases are 15 years old and while
they can remain on older versions of PHP, an LTS build would be very helpful ...
one can target that for upgrading old code and then move forward if needed. Heck
some projects have only just closed down PHP4 support on their trunk ...
--
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
So we'd always have three branches, while two only receive bug fixes,
plus one branch for the next milestone.johannes
+1 for the new release cycle, and +1 for making 5.3 for the next LTS.
Tyrael
2010/8/10 Johannes Schlüter johannes@php.net:
Yes. Release early, release often is a good thing. What I'd also like is
to have a Ubuntu-like support model. Where we have one LTS (long term
supported) version (now for instance 5.3) which will get bug fixes for
quite some time and an "early access" version (5.4) which will receive
updates until the next "early access" (5.5) is there.
I'm happy with the three branches idea, but I do have some concerns
about an LTS model:
– The LTS branch is going to become more and more difficult to
backport fixes to as it diverges from the other two branches, and I
can see developers not bothering after a certain point, which may be
counter productive.
– Documenting how functionality changes from version to version in the
manual is already a weak point, judging by some of the bugs and
feedback we get: users don't always grok the version bylines and
change log tables in the function reference as it is, and that's with
a more closely aligned set of active branches. We might end up needing
to rethink how we structure the manual by looking at something like
the Python approach of having separate manuals for separate versions,
which would require a not-insignificant amount of work.
– It might be hard to communicate why 5.4 (in the example you
included) becomes end of lifed while 5.3 lives on. I guess that's no
different to Ubuntu, though.
– Will downstream distributors want to ship non-LTS versions? This
might actually reduce the amount of useful feedback we get for (again,
using your example) 5.4, 5.5 and 5.6 releases, which might not be a
great thing for the stability of the next LTS (6.0) release.
So we'd always have three branches, while two only receive bug fixes,
plus one branch for the next milestone.
As I said, I have no qualms with this, particularly in light of some
of the articles that have been doing the rounds about 5.2's end of
lifing.* Under this system, and without an LTS structure, our current
situation would be a bit different, with both 5.2 and 5.3 getting bug
fixes until trunk is released (at which point 5.2 would be EOL), which
I think would suit users a bit better.
Adam
- Yes, I know it's not actually EOL, but that's been another
communication challenge.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
We might end up needing
to rethink how we structure the manual by looking at something like
the Python approach of having separate manuals for separate versions,
which would require a not-insignificant amount of work.
As an PHP developer: Providing manuals based on version sounds like a
good idea. But I'm not sure about the amount of additional work involved
and the willingness of docs contributors to do this..
– Will downstream distributors want to ship non-LTS versions?
As Gentoo downstream: yes, sure. Not so sure about Ubuntu and other
binary-based distributions, as long as you don't fit into their LTS
release cycle.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxhHhkACgkQfNMcoUhJ7GxubgCZAe5cjy3COOX0/y5ChpqoMaxd
ZnMAnigNMR0CbKHL/Ky7EkM2EvgMioyJ
=AEUz
-----END PGP SIGNATURE
As an PHP developer: Providing manuals based on version sounds like a
good idea. But I'm not sure about the amount of additional work involved
and the willingness of docs contributors to do this..
Thats a heckofamore work then we have man power for.
The manual have explicit inline notes about every change, and features
only available in certain versions are clearly noted.
I really don't see the usecase for version specific manuals - you
should be aware of the changes, past and future, so you can make up
your own mind on which version your application should run - and be
able to write future compatible code.
-Hannes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
As an PHP developer: Providing manuals based on version sounds like a
good idea. But I'm not sure about the amount of additional work involved
and the willingness of docs contributors to do this..Thats a heckofamore work then we have man power for.
Okay, point taken.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkxhIjMACgkQfNMcoUhJ7GzQzwCgkHNgc0ea0r6j1VUtWYaCGNqF
VE4An3lSzlseFi3FIPDMM2A6avG2Bj2y
=RwyU
-----END PGP SIGNATURE
– The LTS branch is going to become more and more difficult to
backport fixes to as it diverges from the other two branches, and I
can see developers not bothering after a certain point, which may be
counter productive.
Except for things like the Unicode branch our code base is quite stable
in most places.
– Documenting how functionality changes from version to version in the
manual is already a weak point, judging by some of the bugs and
feedback we get: users don't always grok the version bylines and
change log tables in the function reference as it is, and that's with
a more closely aligned set of active branches. We might end up needing
to rethink how we structure the manual by looking at something like
the Python approach of having separate manuals for separate versions,
which would require a not-insignificant amount of work.
In the LTS the functionality shouldn't change (having shorter cycles
even between other bug fix releases) Yes there are exceptions where a
needed bug fix has an effect, but documenting this should be solvable.
– It might be hard to communicate why 5.4 (in the example you
included) becomes end of lifed while 5.3 lives on. I guess that's no
different to Ubuntu, though.
Better naming than simply "5.3", "5.4" ... might help. But should be
solvable.
– Will downstream distributors want to ship non-LTS versions? This
might actually reduce the amount of useful feedback we get for (again,
using your example) 5.4, 5.5 and 5.6 releases, which might not be a
great thing for the stability of the next LTS (6.0) release.
Distributors should be able to distribute two versions. Some do/did with
PHP 4 and PHP 5. And I prefer distributions offering the bug fix
releases for the LTS version over a heavily patched outdated 5.1.6 like
RedHat does.
johannes
2010/8/10 Johannes Schlüter johannes@php.net:
– The LTS branch is going to become more and more difficult to
backport fixes to as it diverges from the other two branches, and I
can see developers not bothering after a certain point, which may be
counter productive.Except for things like the Unicode branch our code base is quite stable
in most places.
Speaking of unicode, did we ever get the intl based mbstring patch into trunk?
-Hannes
So we'd always have three branches, while two only receive bug fixes,
plus one branch for the next milestone.
That's exactly what we have now: 5.2, 5.3 and trunk. I think your LTS
idea is way too optimistic. I really don't care about porting bug fixes
back to 5.2 because it is four years old. PHP 5.3 has been out for a
year. Right now there are not many API differences, but it does cost
extra time to maintain. Time we should rather spend on getting new
things out. Leave the 5.2 support to the distributions!
regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
2010/8/10 Derick Rethans derick@php.net:
That's exactly what we have now: 5.2, 5.3 and trunk. I think your LTS
idea is way too optimistic. I really don't care about porting bug fixes
back to 5.2 because it is four years old. PHP 5.3 has been out for a
year. Right now there are not many API differences, but it does cost
extra time to maintain. Time we should rather spend on getting new
things out. Leave the 5.2 support to the distributions!
In terms of backporting fixes (talking more generally about the three
branch model and not so much about 5.2 in particular), between PHP and
other projects I'm involved with, I'm acutely aware of the pain there.
Honestly, though, I'm not entirely comfortable just leaving it up to
distributions: plenty of people run hand-built versions of PHP, and
testing large codebases with new branches of PHP isn't always as quick
a process as it should be.
Or, put another way, just because I'm lucky enough to be able to run
my code on the bleeding edge doesn't mean I don't feel a little bit
obligated towards people who aren't that lucky. :)
Adam
Yes. Release early, release often is a good thing. What I'd also like is
to have a Ubuntu-like support model. Where we have one LTS (long term
supported) version (now for instance 5.3) which will get bug fixes for
quite some time and an "early access" version (5.4) which will receive
updates until the next "early access" (5.5) is there.Reasons:
* Give people early access to features * Motivate developers as their additions are in a reachable future * Give users the chance to stay on the LTS version without having to do the full update on every release * Reduce the number of changes in "bugfix" releases
Is LTS really something we need to provide? Seems to me like this is something the linux vendors take care of for the most part. Of course this leaves windows, OSX (and maybe some others).
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
2010/8/10 Lukas Kahwe Smith mls@pooteeweet.org:
Yes. Release early, release often is a good thing. What I'd also like is
to have a Ubuntu-like support model. Where we have one LTS (long term
supported) version (now for instance 5.3) which will get bug fixes for
quite some time and an "early access" version (5.4) which will receive
updates until the next "early access" (5.5) is there.Reasons:
* Give people early access to features
* Motivate developers as their additions are in a reachable future
* Give users the chance to stay on the LTS version without having
to do the full update on every release
* Reduce the number of changes in "bugfix" releasesIs LTS really something we need to provide? Seems to me like this is something the linux vendors take care of for the most part. Of course this leaves windows, OSX (and maybe some others).
We have to provide a well defined life cycle for our releases. The way
we do it now is not good, not for linux distros and not for
developers. It is impossible to get a mid term visibility.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Is LTS really something we need to provide? Seems to me like this is
something the linux vendors take care of for the most part. Of course
this leaves windows, OSX (and maybe some others).
Well, I don't see it as loooooooooooooooooooooooooong term support, but
rather as way to enable quick feature cycles, so that feature releases
can move faster than anybody can upgrade to them (ok, that's a bit too
fast the, but hope you get the point), while new features can get in
production sooner, where wanted.
We could also use the names "feature preview release" and "stable
release"(=lts) ... which would bring us close to MySQL's model and their
confusing version numbering (MySQL 5.1 is the stable there, then MySQL
5.4 was announced as preview, now MySQL 5.5 is the current preview
release, neither 5.4 nor 5.5 are "stable", "GA", though)
johanne
2010/8/10 Johannes Schlüter johannes@schlueters.de
Is LTS really something we need to provide? Seems to me like this is
something the linux vendors take care of for the most part. Of course
this leaves windows, OSX (and maybe some others).Well, I don't see it as loooooooooooooooooooooooooong term support, but
rather as way to enable quick feature cycles, so that feature releases
can move faster than anybody can upgrade to them (ok, that's a bit too
fast the, but hope you get the point), while new features can get in
production sooner, where wanted.We could also use the names "feature preview release" and "stable
release"(=lts) ... which would bring us close to MySQL's model and their
confusing version numbering (MySQL 5.1 is the stable there, then MySQL
5.4 was announced as preview, now MySQL 5.5 is the current preview
release, neither 5.4 nor 5.5 are "stable", "GA", though)johanne
they started to use milestone release-s.
http://dev.mysql.com/tech-resources/articles/mysql-release-model.html
http://dev.mysql.com/tech-resources/articles/mysql-release-model.html
Tyrael
Ferenc Kovacs wrote:
2010/8/10 Johannes Schlüter johannes@schlueters.de
Is LTS really something we need to provide? Seems to me like this is
something the linux vendors take care of for the most part. Of course
this leaves windows, OSX (and maybe some others).
Well, I don't see it as loooooooooooooooooooooooooong term support, but
rather as way to enable quick feature cycles, so that feature releases
can move faster than anybody can upgrade to them (ok, that's a bit too
fast the, but hope you get the point), while new features can get in
production sooner, where wanted.We could also use the names "feature preview release" and "stable
release"(=lts) ... which would bring us close to MySQL's model and their
confusing version numbering (MySQL 5.1 is the stable there, then MySQL
5.4 was announced as preview, now MySQL 5.5 is the current preview
release, neither 5.4 nor 5.5 are "stable", "GA", though)johanne
they started to use milestone release-s.
http://dev.mysql.com/tech-resources/articles/mysql-release-model.htmlhttp://dev.mysql.com/tech-resources/articles/mysql-release-model.html
Tyrael
Which are even more confusing. But someone had to spend hours paid time
to think this out.
Andrey
Is LTS really something we need to provide? Seems to me like this is
something the linux vendors take care of for the most part. Of course
this leaves windows, OSX (and maybe some others).Well, I don't see it as loooooooooooooooooooooooooong term support, but
Using LTS as a term confused me on that one :P
rather as way to enable quick feature cycles, so that feature releases
can move faster than anybody can upgrade to them (ok, that's a bit too
fast the, but hope you get the point), while new features can get in
production sooner, where wanted.We could also use the names "feature preview release" and "stable
release"(=lts) ... which would bring us close to MySQL's model and their
confusing version numbering (MySQL 5.1 is the stable there, then MySQL
5.4 was announced as preview, now MySQL 5.5 is the current preview
release, neither 5.4 nor 5.5 are "stable", "GA", though)
I still don't think this is a good idea though. That would me we have
(as example) 5.2 in LTS, 5.6 as stable and 5.7 in trunk? How much do you
(at that point) like supporting a 4/5 year old version? Do you hvae that
much spare time?
I think our current way work pretty well. There is 5.2 which is
security-fix supported, 5.3 that is supported and trunk/5.4 that's on
the way to alpha.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Am 10.08.2010 17:14, schrieb Derick Rethans:
I think our current way work pretty well. There is 5.2 which is
security-fix supported, 5.3 that is supported and trunk/5.4 that's on
the way to alpha.
This only works if manage to keep the time between "new code is
committed to trunk" and "new code is released" under a year. Otherwise
developers get frustrated.
If we manage to release a PHP 5.X.0 release every year, we are a lot
more predictable. Which is good for downstream as well.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Am 10.08.2010 17:14, schrieb Derick Rethans:
I think our current way work pretty well. There is 5.2 which is
security-fix supported, 5.3 that is supported and trunk/5.4 that's on
the way to alpha.This only works if manage to keep the time between "new code is
committed to trunk" and "new code is released" under a year. Otherwise
developers get frustrated.If we manage to release a PHP 5.X.0 release every year, we are a lot
more predictable. Which is good for downstream as well.
+1
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Am 10.08.2010 17:14, schrieb Derick Rethans:
I think our current way work pretty well. There is 5.2 which is
security-fix supported, 5.3 that is supported and trunk/5.4 that's on
the way to alpha.This only works if manage to keep the time between "new code is
committed to trunk" and "new code is released" under a year. Otherwise
developers get frustrated.If we manage to release a PHP 5.X.0 release every year, we are a lot
more predictable. Which is good for downstream as well.
Yes, and that's why I want 5.4 alpha1 out soonish...
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Am 10.08.2010 17:25, schrieb Derick Rethans:
Yes, and that's why I want 5.4 alpha1 out soonish...
Exactly.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
Yes, and that's why I want 5.4 alpha1 out soonish...
s,want,would like to,
Even if you were the RM, that's not your call. Tired of seeing doing
the same thing again and again.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Am 10.08.2010 17:14, schrieb Derick Rethans:
I think our current way work pretty well. There is 5.2 which is
security-fix supported, 5.3 that is supported and trunk/5.4 that's on
the way to alpha.This only works if manage to keep the time between "new code is
committed to trunk" and "new code is released" under a year. Otherwise
developers get frustrated.If we manage to release a PHP 5.X.0 release every year, we are a lot
more predictable. Which is good for downstream as well.
That's exactly what I keep asking. It also requires some changes about
features addition in stable releases, bugs fixes and release life
cycles. All these words sounds like a nightmare to Derick&co, but
that's something we have to go through. It is the only way to have
controllable and plan-able releases (for us, our users and the
distros).
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
2010/8/10 Derick Rethans derick@php.net
Is LTS really something we need to provide? Seems to me like this is
something the linux vendors take care of for the most part. Of course
this leaves windows, OSX (and maybe some others).Well, I don't see it as loooooooooooooooooooooooooong term support, but
Using LTS as a term confused me on that one :P
rather as way to enable quick feature cycles, so that feature releases
can move faster than anybody can upgrade to them (ok, that's a bit too
fast the, but hope you get the point), while new features can get in
production sooner, where wanted.We could also use the names "feature preview release" and "stable
release"(=lts) ... which would bring us close to MySQL's model and their
confusing version numbering (MySQL 5.1 is the stable there, then MySQL
5.4 was announced as preview, now MySQL 5.5 is the current preview
release, neither 5.4 nor 5.5 are "stable", "GA", though)I still don't think this is a good idea though. That would me we have
(as example) 5.2 in LTS, 5.6 as stable and 5.7 in trunk? How much do you
(at that point) like supporting a 4/5 year old version? Do you hvae that
much spare time?I think our current way work pretty well. There is 5.2 which is
security-fix supported, 5.3 that is supported and trunk/5.4 that's on
the way to alpha.Derick
From the ubuntu wiki:
"A new LTS version is usually released every 2 years. With the Long Term
Support (LTS) version you get 3 years support on Ubuntu Desktop, and 5 years
on Ubuntu Server. There is no extra fee for the LTS version; we make our
very best work available to everyone on the same free terms. Upgrades to new
versions of Ubuntu are and always will be free of charge."
So with this release policy comes the following terms:
- the releases coming in a timely manner.
- normal release gets support until the next release comes out.
- an LTS release gets support until a pre-defined time interval(and we
promise we will release the next LTS until that time). - you have an upgrade-path from a version to the next one.
- you have an upgrade-path from an lts version to the next lts.
we could change the interval-s to suit our needs, but with this policy, the
early-adopters could use and test the new features earlier, but the lazy
devs are allowed to upgrade only with the EOL of the LTS.
with the new approach we could release a new major version much faster and
smaller changeset.
I would suggest the 5.3 branch for the first LTS
what are your thoughts about the optimal timeframe for a normal/LTS php
release?
I would prefer 6-12 months for a release, and 2-3 years for an LTS (this is
why we shouldn't start the LTS with the already old 5.2 branch )
Tyrael
Is LTS really something we need to provide? Seems to me like this is
something the linux vendors take care of for the most part. Of course
this leaves windows, OSX (and maybe some others).Well, I don't see it as loooooooooooooooooooooooooong term support, but
Using LTS as a term confused me on that one :P
Yeah, I didn't focus on the release earl, often fact enough.
rather as way to enable quick feature cycles, so that feature releases
can move faster than anybody can upgrade to them (ok, that's a bit too
fast the, but hope you get the point), while new features can get in
production sooner, where wanted.We could also use the names "feature preview release" and "stable
release"(=lts) ... which would bring us close to MySQL's model and their
confusing version numbering (MySQL 5.1 is the stable there, then MySQL
5.4 was announced as preview, now MySQL 5.5 is the current preview
release, neither 5.4 nor 5.5 are "stable", "GA", though)I still don't think this is a good idea though. That would me we have
(as example) 5.2 in LTS, 5.6 as stable and 5.7 in trunk? How much do you
(at that point) like supporting a 4/5 year old version? Do you hvae that
much spare time?I think our current way work pretty well. There is 5.2 which is
security-fix supported, 5.3 that is supported and trunk/5.4 that's on
the way to alpha.
Well, maintaining them becomes simpler if we change less features. Like
adding a new SAPI in x.y.3 and lots of stuff in x.y.2. And for doing
this we need shorter cycles.
There is always small stuff, like simple functions, which misses a .0
release. Now committing them to trunk means they appear for earl
adapters for the next version 1.5 to 2 years later. For the developers
it is is stupid to hold a small "harmless" addition back so what are we
doing - we're backporting stuff. Tons of stuff.
If we shorten the cycle by which features become available in a
"stable"/"feature preview"/... version we do have to care less about
backporting, which makes handling of the released branches simpler.
On the other side short cycles are bad for getting people to migrate,
that's why there are longer supported releases.
Now having distributors doing the backporting is nice for our workload
(distributor package -> bogus bug report) but then one has to choose a
distribution where you like the environment (what inisystem, what
packagemanager etc.) and which doesn't break the timezone database or
something else.
johannes
hi,
With the recent additions to 5.4, aren't we getting closer to have a
public alpha release, or just a development test as we have many great
additions and changes to the current trunk or atleast set up some sort
of roadmap for what we all like to have in 5.4, or be that 6.0 as
thats yet another thing we should get settled soonish.Huge -1 here.
We are light years away to even be able to define what will be
php-next. Let discuss that September, at the soonest.I could not disagree more. I think one of the key lessons we should
have learned out of the whole 6.0 saga was that "release early,
release often" is a good thing
The key lesson of PHP 6 is that the lack of consensus, decision
process, design, clear roadmap and release process leads to chaos,
frustration and dead cows.
But from a technical point of view, yes, we have almost every thing to
begin to think about php-next.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
http://news.php.net/php.internals/49186
I hope 5.4 beta complete support LFS.
-----邮件原件-----
发件人: kalle.php@gmail.com [mailto:kalle.php@gmail.com] 代表 Kalle Sommer
Nielsen
发送时间: 2010年8月10日 5:56
收件人: Internals
主题: [PHP-DEV] 5.4 Alpha?
Greetings geeks
With the recent additions to 5.4, aren't we getting closer to have a public
alpha release, or just a development test as we have many great additions
and changes to the current trunk or atleast set up some sort of roadmap for
what we all like to have in 5.4, or be that 6.0 as thats yet another thing
we should get settled soonish.
--
regards,
Kalle Sommer Nielsen
kalle@php.net
--
To unsubscribe, visit:
http://www.php.net/unsub.php
With the recent additions to 5.4, aren't we getting closer to have a
public alpha release, or just a development test as we have many great
additions and changes to the current trunk or atleast set up some sort
of roadmap for what we all like to have in 5.4, or be that 6.0 as
thats yet another thing we should get settled soonish.
I'd say: let's do 5.4-alpha! There's plenty of cool stuff in trunk.
regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
On Tue, Aug 10 2010, Derick Rethans wrote
With the recent additions to 5.4, aren't we getting closer to have a
public alpha release, or just a development test as we have many
great
additions and changes to the current trunk or atleast set up some
sort
of roadmap for what we all like to have in 5.4, or be that 6.0 as
thats yet another thing we should get settled soonish.
I'd say: let's do 5.4-alpha! There's plenty of cool stuff in trunk.
Absolutely.
Humbly, if the "release early, release often" mantra is to be [re-]embraced,
I'd say start right now.
Best Regards,
Mike Robinson