Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » PHP 5.1.2 Release Plan »

PHP 5.1.2 Release Plan

php.internals

Ilia A.

20 years ago
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

Andi Gutmans

20 years ago
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:

Ilia A.

20 years ago
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

Jani Taskinen

20 years ago
On Wed, 30 Nov 2005, Andi Gutmans wrote:
> Is our confidence level on xmlwriter high? Just asking as I'm not sure how
It's very high. I need it too. :) --Jani

Jani Taskinen

20 years ago
On Wed, 30 Nov 2005, Ilia Alshanetsky wrote:
> * 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

Rasmus Lerdorf

20 years ago
Jani Taskinen wrote:
> On Wed, 30 Nov 2005, Ilia Alshanetsky wrote: > >> * 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?! :)
One of the reasons is that this would be the first extension we bundle which isn't under the PHP license. -Rasmus

Jani Taskinen

20 years ago
On Thu, 1 Dec 2005, Rasmus Lerdorf wrote:
> > Jani Taskinen wrote: >> On Wed, 30 Nov 2005, Ilia Alshanetsky wrote: >> >>> * 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?! :) > > 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

Rasmus Lerdorf

20 years ago
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

Marcus Börger

20 years ago
Hello Rasmus, Thursday, December 1, 2005, 10:08:41 AM, you wrote:
> 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.
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

Rob Richards

20 years ago
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

Pierre Joye

20 years ago
On Thu, 01 Dec 2005 14:30:07 +0530 rasmus@lerdorf.com (Rasmus Lerdorf) wrote:
> Jani Taskinen wrote: > > On Wed, 30 Nov 2005, Ilia Alshanetsky wrote: > > > >> * 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?! :) > > 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

Ilia A.

20 years ago
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

Marcus Börger

20 years ago
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: >> 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
Best regards, Marcus

Pierre Joye

20 years ago
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

Marcus Börger

20 years ago
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:
>> 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.
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

Jani Taskinen

20 years ago
You forgot one thing: pecl/filter ! It definately should be included, with the EXPERIMENTAL flag of course. --Jani

Ants Aasma

20 years ago
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

Derick Rethans

20 years ago
> * 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.

Pierre Joye

20 years ago
On Tue, 06 Dec 2005 09:03:16 +0100 derick@php.net (Derick Rethans) wrote:
> > * 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...
It is already done since last week. And I still do not have some good explanation about this new requirement. --Pierre

Lukas Smith

20 years ago
Pierre wrote:
> On Tue, 06 Dec 2005 09:03:16 +0100 > derick@php.net (Derick Rethans) wrote: > > >>>* 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... > > > 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

Stefan Walk

20 years ago
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

Rasmus Lerdorf

20 years ago
Pierre wrote:
> On Tue, 06 Dec 2005 09:03:16 +0100 > derick@php.net (Derick Rethans) wrote: > >>> * 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... > > 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

Pierre Joye

20 years ago
On Tue, 06 Dec 2005 10:53:37 -0800 rasmus@lerdorf.com (Rasmus Lerdorf) wrote:
> Pierre wrote: > > On Tue, 06 Dec 2005 09:03:16 +0100 > > derick@php.net (Derick Rethans) wrote: > > > >>> * 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... > > > > 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.
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

Zeev Suraski

20 years ago
At 23:51 06/12/2005, Pierre wrote:
>On Tue, 06 Dec 2005 10:53:37 -0800 >rasmus@lerdorf.com (Rasmus Lerdorf) wrote: > > > Pierre wrote: > > > On Tue, 06 Dec 2005 09:03:16 +0100 > > > derick@php.net (Derick Rethans) wrote: > > > > > >>> * 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... > > > > > > 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. > >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?
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