# 5.4 Alpha? - Thread: https://externals.io/message/49232 - Original archive: https://news-web.php.net/php.internals/49232 - Started by Kalle Sommer Nielsen on 2010-08-09T21:56:20+00:00 - Messages: 33 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/49232.md?page=2 - 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 --- ## #49232 — Kalle Sommer Nielsen — 2010-08-09T21:56:20+00:00 URL: https://externals.io/message/49232#49232 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 --- ## #49233 — Pierre Joye — 2010-08-09T23:28:28+00:00 URL: https://externals.io/message/49232#49233 · In reply to: #49232 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 --- ## #49236 — gaochunhui@gmail.com — 2010-08-10T00:34:43+00:00 URL: https://externals.io/message/49232#49236 · In reply to: #49232 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 --- ## #49238 — Adam Harvey — 2010-08-10T02:19:27+00:00 URL: https://externals.io/message/49232#49238 · In reply to: #49233 > > > […] > 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. :) --- ## #49241 — johannes@php.net — 2010-08-10T08:45:40+00:00 URL: https://externals.io/message/49232#49241 · In reply to: #49238 > 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 --- ## #49242 — Sebastian Bergmann — 2010-08-10T08:57:37+00:00 URL: https://externals.io/message/49232#49242 · In reply to: #49241 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/ --- ## #49243 — Lester Caine — 2010-08-10T09:15:26+00:00 URL: https://externals.io/message/49232#49243 · In reply to: #49242 Sebastian Bergmann wrote: > > […] > +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 --- ## #49244 — Ferenc Kovacs — 2010-08-10T09:25:28+00:00 URL: https://externals.io/message/49232#49244 · In reply to: #49241 > > > 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 --- ## #49245 — Adam Harvey — 2010-08-10T09:25:43+00:00 URL: https://externals.io/message/49232#49245 · In reply to: #49241 2010/8/10 Johannes Schlüter : > 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. --- ## #49246 — Matti Bickel — 2010-08-10T09:38:33+00:00 URL: https://externals.io/message/49232#49246 · In reply to: #49245 -----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 --- ## #49247 — Pierre Joye — 2010-08-10T09:43:27+00:00 URL: https://externals.io/message/49232#49247 · In reply to: #49238 hi, > > > […] > > 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 --- ## #49248 — johannes@php.net — 2010-08-10T09:43:51+00:00 URL: https://externals.io/message/49232#49248 · In reply to: #49245 > – 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 --- ## #49249 — Hannes Magnusson — 2010-08-10T09:47:18+00:00 URL: https://externals.io/message/49232#49249 · In reply to: #49246 > > 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 --- ## #49250 — Hannes Magnusson — 2010-08-10T09:48:13+00:00 URL: https://externals.io/message/49232#49250 · In reply to: #49248 2010/8/10 Johannes Schlüter : > > > […] > > 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 --- ## #49251 — Matti Bickel — 2010-08-10T09:56:03+00:00 URL: https://externals.io/message/49232#49251 · In reply to: #49249 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > > […] > > 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 --- ## #49252 — Derick Rethans — 2010-08-10T10:50:52+00:00 URL: https://externals.io/message/49232#49252 · In reply to: #49241 > 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 --- ## #49254 — Derick Rethans — 2010-08-10T11:10:01+00:00 URL: https://externals.io/message/49232#49254 · In reply to: #49232 > 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 --- ## #49255 — Adam Harvey — 2010-08-10T13:45:45+00:00 URL: https://externals.io/message/49232#49255 · In reply to: #49252 2010/8/10 Derick Rethans : > 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 --- ## #49256 — Lukas Kahwe Smith — 2010-08-10T14:20:35+00:00 URL: https://externals.io/message/49232#49256 · In reply to: #49241 > > > 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 --- ## #49257 — Pierre Joye — 2010-08-10T14:25:23+00:00 URL: https://externals.io/message/49232#49257 · In reply to: #49256 2010/8/10 Lukas Kahwe Smith : > > > > > […] > > > 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). 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 --- ## #49258 — johannes@schlueters.de — 2010-08-10T14:30:42+00:00 URL: https://externals.io/message/49232#49258 · In reply to: #49256 > 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 --- ## #49259 — Ferenc Kovacs — 2010-08-10T15:07:08+00:00 URL: https://externals.io/message/49232#49259 · In reply to: #49258 2010/8/10 Johannes Schlüter > > > […] > > 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 Tyrael --- ## #49260 — Derick Rethans — 2010-08-10T15:14:11+00:00 URL: https://externals.io/message/49232#49260 · In reply to: #49258 > > > […] > > 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 --- ## #49261 — Sebastian Bergmann — 2010-08-10T15:20:40+00:00 URL: https://externals.io/message/49232#49261 · In reply to: #49260 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/ --- ## #49263 — Lukas Kahwe Smith — 2010-08-10T15:24:26+00:00 URL: https://externals.io/message/49232#49263 · In reply to: #49261 > Am 10.08.2010 17:14, schrieb Derick Rethans: > > […] > > 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 --- Next page: https://externals.io/message/49232.md?page=2