# PHP 5.1.2 Release Plan - Thread: https://externals.io/message/20929 - Original archive: https://news-web.php.net/php.internals/20929 - Started by Ilia Alshanetsky on 2005-12-01T04:10:34+00:00 - Messages: 24 - 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 --- ## #20929 — Ilia Alshanetsky — 2005-12-01T04:10:34+00:00 URL: https://externals.io/message/20929#20929 Here is a brief outline of how I see 5.1.2 release happening and what in my opinion should be included in the release. This is very much an RFC as far as the changes go, so feel free to comment. First the release plan, my idea is to allow minor features with accompanying tests that do not introduce any BC issues or functionality regressions till the 10th of December. At this point we would go into a feature and major change lock down, till about 22nd of December when the first RC will be made. Through out this time only bug fixes will be allowed and on Jan. 5th RC2 will be released. From that point we would go into the final release stage at which point nothing short of critical bug fixes be allowed. Assuming a 1 week period without such fixes passes, final release will be tagged, making the last RC essentially that release. In the even critical issues are discovered, additional RCs will be rolled. Date Summary: (not be confused with date extension ;-) ) Until Dec. 10, 2005: Minor features and bug fixes requiring major changes Dec. 22, 2005: RC1 Jan. 05, 2006: RC2 Jan. 12, 2006: Final (pending critical issues since RC2) Planned Changes: * Resolve all currently opened Engine bugs, ideally 5.1.2 will be released without any unresolved engine problems. * Resolve all currently open PDO bugs. * Enable xmlreader extension by default, as we do for all XML extensions. * Introduce hash extension via a symlink from pecl into core. This extension introduces native implementation of common hash algorithms with streams support, making it an excellent solution for people requiring better hashing then provided by md5/sha1. Merits of this extensions have been discussed on this list few weeks ago, just scroll past the recent flame wars ;-) * Introduce xmlwriter extension via a symlink from pecl into core and as other XML extension enable it by default. * Backport oci extension into 5.1, this is mostly for bug fixing reasons, as the new code fixes over a dozen bug reports in that extension. Ilia --- ## #20930 — Andi Gutmans — 2005-12-01T05:09:51+00:00 URL: https://externals.io/message/20929#20930 · In reply to: #20929 Sounds like a good plan to me. Is our confidence level on xmlwriter high? Just asking as I'm not sure how broadly it's been used and if we expect the API to have limitations or require changing at some point. Thx Ilia! At 08:10 PM 11/30/2005, Ilia Alshanetsky wrote: >Here is a brief outline of how I see 5.1.2 release happening and what in >my opinion should be included in the release. This is very much an RFC >as far as the changes go, so feel free to comment. > >First the release plan, my idea is to allow minor features with >accompanying tests that do not introduce any BC issues or functionality >regressions till the 10th of December. At this point we would go into a >feature and major change lock down, till about 22nd of December when the >first RC will be made. Through out this time only bug fixes will be >allowed and on Jan. 5th RC2 will be released. From that point we would >go into the final release stage at which point nothing short of critical >bug fixes be allowed. Assuming a 1 week period without such fixes >passes, final release will be tagged, making the last RC essentially >that release. In the even critical issues are discovered, additional RCs >will be rolled. > >Date Summary: (not be confused with date extension ;-) ) > >Until Dec. 10, 2005: Minor features and bug fixes requiring major changes >Dec. 22, 2005: RC1 >Jan. 05, 2006: RC2 >Jan. 12, 2006: Final (pending critical issues since RC2) > >Planned Changes: > >* Resolve all currently opened Engine bugs, ideally 5.1.2 will be > released without any unresolved engine problems. >* Resolve all currently open PDO bugs. >* Enable xmlreader extension by default, as we do for all XML > extensions. >* Introduce hash extension via a symlink from pecl into core. > This extension introduces native implementation of common hash > algorithms with streams support, making it an excellent solution > for people requiring better hashing then provided by md5/sha1. > Merits of this extensions have been discussed on this list few > weeks ago, just scroll past the recent flame wars ;-) >* Introduce xmlwriter extension via a symlink from pecl into core and as > other XML extension enable it by default. >* Backport oci extension into 5.1, this is mostly for bug fixing > reasons, as the new code fixes over a dozen bug reports in that > extension. > >Ilia --- ## #20931 — Ilia Alshanetsky — 2005-12-01T05:20:14+00:00 URL: https://externals.io/message/20929#20931 · In reply to: #20930 Andi Gutmans wrote: > Sounds like a good plan to me. > Is our confidence level on xmlwriter high? I'd say, so. > Just asking as I'm not sure > how broadly it's been used and if we expect the API to have limitations > or require changing at some point. My understanding is that the API is pretty much "set", but I hope Pierre and/or Rob can re-confirm this. Ilia --- ## #20937 — Jani Taskinen — 2005-12-01T08:55:12+00:00 URL: https://externals.io/message/20929#20937 · In reply to: #20930 > Is our confidence level on xmlwriter high? Just asking as I'm not sure how It's very high. I need it too. :) --Jani --- ## #20938 — Jani Taskinen — 2005-12-01T08:56:43+00:00 URL: https://externals.io/message/20929#20938 · In reply to: #20929 > * Enable xmlreader extension by default, as we do for all XML > extensions. Done. Also made it use the right configure option. > * Introduce xmlwriter extension via a symlink from pecl into core and as > other XML extension enable it by default. Why isn't it done yet?! :) --Jani --- ## #20939 — Rasmus Lerdorf — 2005-12-01T09:00:07+00:00 URL: https://externals.io/message/20929#20939 · In reply to: #20938 Jani Taskinen wrote: > > > > […] > > Done. Also made it use the right configure option. > > > […] > > Why isn't it done yet?! :) One of the reasons is that this would be the first extension we bundle which isn't under the PHP license. -Rasmus --- ## #20940 — Jani Taskinen — 2005-12-01T09:01:33+00:00 URL: https://externals.io/message/20929#20940 · In reply to: #20938 You forgot one thing: pecl/filter ! It definately should be included, with the EXPERIMENTAL flag of course. --Jani --- ## #20941 — Jani Taskinen — 2005-12-01T09:02:56+00:00 URL: https://externals.io/message/20929#20941 · In reply to: #20939 > > Jani Taskinen wrote: > > […] > > One of the reasons is that this would be the first extension we bundle which > isn't under the PHP license. Isn't that solved by just simply changing the license by the author? --Jani --- ## #20942 — Rasmus Lerdorf — 2005-12-01T09:08:41+00:00 URL: https://externals.io/message/20929#20942 · In reply to: #20941 Jani Taskinen wrote: > Isn't that solved by just simply changing the license by the author? Sure, but until that happens I don't think it should be included. -Rasmus --- ## #20943 — Marcus Boerger — 2005-12-01T09:52:30+00:00 URL: https://externals.io/message/20929#20943 · In reply to: #20942 Hello Rasmus, Thursday, December 1, 2005, 10:08:41 AM, you wrote: > Jani Taskinen wrote: > > […] > Sure, but until that happens I don't think it should be included. Same here. The discussion was on IRC and between Rob & Pierre and i thought they changed back but didn't do so yet. Best regards, Marcus --- ## #20945 — Rob Richards — 2005-12-01T11:43:21+00:00 URL: https://externals.io/message/20929#20945 · In reply to: #20943 Marcus Boerger wrote: > Sure, but until that happens I don't think it should be included. > > > Same here. The discussion was on IRC and between Rob & Pierre and i thought > they changed back but didn't do so yet. > The license is changing. It was actually supposed to have changed yesterday. Pierre needed a little time to straighten things out before the change. If it's not done before I get to the office I'll change it myself as it's also holding up a release since I wouldn't do a new PECL release until the license was changed. It is stable - the release is to make it build under 5.0 again. Rob --- ## #20946 — Pierre — 2005-12-01T12:20:00+00:00 URL: https://externals.io/message/20929#20946 · In reply to: #20939 On Thu, 01 Dec 2005 14:30:07 +0530 rasmus@lerdorf.com (Rasmus Lerdorf) wrote: > Jani Taskinen wrote: > > […] > > One of the reasons is that this would be the first extension we > bundle which isn't under the PHP license. This is not a valid reason. But it is not a problem either, as I said, we will change the license back to PHP License, as you finally fix the little problems in the PHP License 3.01, thanks for that :) Regards --Pierre --- ## #20957 — Ilia Alshanetsky — 2005-12-01T16:01:07+00:00 URL: https://externals.io/message/20929#20957 · In reply to: #20939 Rasmus Lerdorf wrote: > One of the reasons is that this would be the first extension we bundle > which isn't under the PHP license. Not a question about xmlwriter specifically, but licensing policy in general. Does your comment imply that only and only extension released under the PHP license are allowed into the "stock" PHP distribution? Or would we allow compatible licenses like BSD, Freeware (ala SQLite lib) , etc... in as well? It may be important to outline this once so that extension writers who put their stuff into PECL and hope for eventual inclusion into core can pick the proper license. Ilia --- ## #20974 — Ants Aasma — 2005-12-01T19:16:03+00:00 URL: https://externals.io/message/20929#20974 · In reply to: #20929 Ilia Alshanetsky wrote: > First the release plan, my idea is to allow minor features with > accompanying tests that do not introduce any BC issues or functionality > regressions till the 10th of December. Bug #35510 add gmp_nextprime function to ext/gmp http://bugs.php.net/bug.php?id=35510 Pretty please :) ------- Ants --- ## #20977 — Marcus Boerger — 2005-12-01T19:52:32+00:00 URL: https://externals.io/message/20929#20977 · In reply to: #20957 Hello Ilia, i prefer only allowing PHP License in 'stock PHP'. marcus Thursday, December 1, 2005, 5:01:07 PM, you wrote: > Rasmus Lerdorf wrote: > > […] > Not a question about xmlwriter specifically, but licensing policy in > general. Does your comment imply that only and only extension released > under the PHP license are allowed into the "stock" PHP distribution? Or > would we allow compatible licenses like BSD, Freeware (ala SQLite lib) > , etc... in as well? It may be important to outline this once so that > extension writers who put their stuff into PECL and hope for eventual > inclusion into core can pick the proper license. > Ilia Best regards, Marcus --- ## #20978 — Pierre — 2005-12-01T19:58:45+00:00 URL: https://externals.io/message/20929#20978 · In reply to: #20977 On Thu, 1 Dec 2005 20:52:32 +0100 helly@php.net (Marcus Boerger) wrote: > Hello Ilia, > > i prefer only allowing PHP License in 'stock PHP'. The question was not what "we" prefer but what is allowed or not, and why. To be a little more precised, I see no reason to not allow BSD-like or other similar license for the extensions. For example the bundled GD is not under the PHP License, or is it already not considered as part of the extension? What difference does that make? --Pierre --- ## #21033 — Marcus Boerger — 2005-12-04T18:01:45+00:00 URL: https://externals.io/message/20929#21033 · In reply to: #20978 Hello Pierre, Thursday, December 1, 2005, 8:58:45 PM, you wrote: > On Thu, 1 Dec 2005 20:52:32 +0100 > helly@php.net (Marcus Boerger) wrote: > > […] > The question was not what "we" prefer but what is allowed or not, and > why. Once again, I am not stupid. > To be a little more precised, I see no reason to not allow BSD-like or > other similar license for the extensions. For example the bundled GD is > not under the PHP License, or is it already not considered as part of > the extension? What difference does that make? I already explained that in private. As long as the core extensions go with the PHP License we can change the license if we decide necessary. If something is done in another license then it is depending on that license whether a change is allowed. Best regards, Marcus --- ## #21058 — Derick Rethans — 2005-12-06T08:03:16+00:00 URL: https://externals.io/message/20929#21058 · In reply to: #20929 > * Introduce xmlwriter extension via a symlink from pecl into core and as > other XML extension enable it by default. Make sure that the licences gets switched back to the PHP license then... Derick ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. --- ## #21059 — Pierre — 2005-12-06T08:08:06+00:00 URL: https://externals.io/message/20929#21059 · In reply to: #21058 On Tue, 06 Dec 2005 09:03:16 +0100 derick@php.net (Derick Rethans) wrote: > > […] > > Make sure that the licences gets switched back to the PHP license > then... It is already done since last week. And I still do not have some good explanation about this new requirement. --Pierre --- ## #21060 — Lukas Smith — 2005-12-06T10:00:07+00:00 URL: https://externals.io/message/20929#21060 · In reply to: #21059 Pierre wrote: > On Tue, 06 Dec 2005 09:03:16 +0100 > derick@php.net (Derick Rethans) wrote: > > > > […] > > > It is already done since last week. > > And I still do not have some good explanation about this new > requirement. Especially given the fact that the main difference is just that no copyright is granted to the PHP Group. Since the PHP Group does not have an army of lawyers at their disposal I do not really see any gain? Then again license things are never simple so facing users with only a single license for everything in PHP is an automatic gain, even if any additional licenses beyond the PHP license added to the mix are actually more lax. IANAL .. yada yada regards, Lukas --- ## #21061 — Stefan Walk — 2005-12-06T10:03:39+00:00 URL: https://externals.io/message/20929#21061 · In reply to: #21060 Hi, Would it be a problem to dual-license the extension? So users/distributors can choose if they want to use it under the PHP License or under BSD/LGPL/whatever. Regards, Stefan --- ## #21065 — Rasmus Lerdorf — 2005-12-06T18:53:37+00:00 URL: https://externals.io/message/20929#21065 · In reply to: #21059 Pierre wrote: > On Tue, 06 Dec 2005 09:03:16 +0100 > derick@php.net (Derick Rethans) wrote: > > > […] > > It is already done since last week. > > And I still do not have some good explanation about this new > requirement. It's not a new requirement. It is simply the status-quo and common sense. All the extensions we bundle are under the same license so people get a tarball with a consistent license and they don't have to wade through a license soup trying to figure out if they meet all the requirements of a bunch of different licenses. We could add extensions with different, but compatible licenses, but there would have to be an *extremely* good reason to do so. -Rasmus --- ## #21066 — Pierre — 2005-12-06T21:51:57+00:00 URL: https://externals.io/message/20929#21066 · In reply to: #21065 On Tue, 06 Dec 2005 10:53:37 -0800 rasmus@lerdorf.com (Rasmus Lerdorf) wrote: > Pierre wrote: > > […] > > It's not a new requirement. It is simply the status-quo and common > sense. Our common senses tend to differ, it is sometimes good to clarify it :-) > All the extensions we bundle are under the same license so > people get a tarball with a consistent license and they don't have to > wade through a license soup trying to figure out if they meet all the > requirements of a bunch of different licenses. We could add > extensions with different, but compatible licenses, but there would > have to be an *extremely* good reason to do so. Well, talking about extensions only, I have not a real big problem but the copyrights, I am reluctant to give the copyrights to the group (and loose it all together), or is it possible to keep original authors besides the PHP group? About the consistent license policy inside a tarball, GDlib is not under the PHP License, for example. Or upcoming bundled libs will have to follow the same policy (lib like in gdlib for example)? About other licences, indeed I was thinking about BSD'ish license for the worst case (and certainly not lgpl&friends as they are more restrictive). Regards, --Pierre --- ## #21067 — Zeev Suraski — 2005-12-07T01:27:27+00:00 URL: https://externals.io/message/20929#21067 · In reply to: #21066 At 23:51 06/12/2005, Pierre wrote: >On Tue, 06 Dec 2005 10:53:37 -0800 >rasmus@lerdorf.com (Rasmus Lerdorf) wrote: > > > […] > >Our common senses tend to differ, it is sometimes good to clarify it :-) > > > […] > >Well, talking about extensions only, I have not a real big problem but >the copyrights, I am reluctant to give the copyrights to the group (and >loose it all together), or is it possible to keep original authors >besides the PHP group? I'm not sure why you care exactly, but from a pure legal standpoint, it complicates things a bit. Does it mean that someone who wants to use PHP in his product name has to also come to you in addition to getting permission from group@php.net? Does it mean we need to get your OK on any future license changes, as minor as they may be? >About the consistent license policy inside a tarball, GDlib is >not under the PHP License, for example. >Or upcoming bundled libs will have to follow the same policy (lib like >in gdlib for example)? > >About other licences, indeed I was thinking about BSD'ish license for >the worst case (and certainly not lgpl&friends as they are more >restrictive). What's wrong with the PHP license? Zeev