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
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
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
Is our confidence level on xmlwriter high? Just asking as I'm not sure how
It's very high. I need it too. :)
--Jani
- 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
Jani Taskinen 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 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
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
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
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
On Thu, 01 Dec 2005 14:30:07 +0530
rasmus@lerdorf.com (Rasmus Lerdorf) wrote:
Jani Taskinen 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
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
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
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
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
You forgot one thing: pecl/filter !
It definately should be included, with the EXPERIMENTAL flag of course.
--Jani
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
- 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.
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
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
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
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
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
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