It's been quite sometime since 5.2 was branched and looking over our
"todo" majority of planned changes were made. Therefor I'd like to
make an RC1 on Thursday next week and start the stabilization cycle
of 5.2, so we can get a final in about 2 months. Once we start
stabilization cycle, no new features will be accepted, so please use
this week to commit any missing new features or major patches that
have been agreed upon and not yet applied.
Ilia Alshanetsky
5.2 Release Master
Ilia Alshanetsky wrote:
It's been quite sometime since 5.2 was branched and looking over our
"todo" majority of planned changes were made. Therefor I'd like to make
an RC1 on Thursday next week and start the stabilization cycle of 5.2,
so we can get a final in about 2 months. Once we start stabilization
cycle, no new features will be accepted, so please use this week to
commit any missing new features or major patches that have been agreed
upon and not yet applied.
I would also appreciate it if people could let me (or Ilia) know of any
todo's already completed (or no longer planed) that are listed on the
todo site:
http://oss.backendmedia.com/PhP52
Open todo items on that page are "assigned" to the following people:
Derick, Georg, Wez, Marcus, Pierre, Ilia, Dmitry, Rasmus, Gopal
regards,
Lukas
Hello Lukas,
Saturday, July 15, 2006, 12:12:12 PM, you wrote:
Ilia Alshanetsky wrote:
It's been quite sometime since 5.2 was branched and looking over our
"todo" majority of planned changes were made. Therefor I'd like to make
an RC1 on Thursday next week and start the stabilization cycle of 5.2,
so we can get a final in about 2 months. Once we start stabilization
cycle, no new features will be accepted, so please use this week to
commit any missing new features or major patches that have been agreed
upon and not yet applied.
I would also appreciate it if people could let me (or Ilia) know of any
todo's already completed (or no longer planed) that are listed on the
todo site:
http://oss.backendmedia.com/PhP52
Open todo items on that page are "assigned" to the following people:
Derick, Georg, Wez, Marcus, Pierre, Ilia, Dmitry, Rasmus, Gopal
I am also very pissed off that neither anybody cared for the upgrade
file nor did those accusing me personally extremley hard cared for
any further updating of that file....thanks again everybody...which
probably means we're back to normal operation modes after everyone
had a free shot...blablabla
Best regards,
Marcus
On Sat, 15 Jul 2006 15:24:26 +0200
helly@php.net (Marcus Boerger) wrote:
Hello Lukas,
Saturday, July 15, 2006, 12:12:12 PM, you wrote:
Ilia Alshanetsky wrote:
It's been quite sometime since 5.2 was branched and looking over
our "todo" majority of planned changes were made. Therefor I'd
like to make an RC1 on Thursday next week and start the
stabilization cycle of 5.2, so we can get a final in about 2
months. Once we start stabilization cycle, no new features will be
accepted, so please use this week to commit any missing new
features or major patches that have been agreed upon and not yet
applied.I would also appreciate it if people could let me (or Ilia) know of
any todo's already completed (or no longer planed) that are listed
on the todo site:
http://oss.backendmedia.com/PhP52Open todo items on that page are "assigned" to the following people:
Derick, Georg, Wez, Marcus, Pierre, Ilia, Dmitry, Rasmus, GopalI am also very pissed off that neither anybody cared for the upgrade
file nor did those accusing me personally extremley hard cared for
any further updating of that file....thanks again everybody...which
probably means we're back to normal operation modes after everyone
had a free shot...blablabla
And now try in english.
What are you trying to say?
For the record, I kept this file updated. And I did update it today
after having discussed with Ilia about the deadlines.
-- Pierre
Ilia Alshanetsky wrote:
It's been quite sometime since 5.2 was branched and looking over our "todo"
majority of planned changes were made. Therefor I'd like to make an RC1 on
Thursday next week and start the stabilization cycle of 5.2, so we can get a
final in about 2 months. Once we start stabilization cycle, no new features
will be accepted, so please use this week to commit any missing new features
or major patches that have been agreed upon and not yet applied.
This caught be a bit by surprise as I was unavailabe the last two weeks,
so I hope I am still in time with my todo items (enabling ext/date
finally, and adding ext/filter with a symlink).
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
On Tue, 18 Jul 2006 14:39:18 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:
Ilia Alshanetsky wrote:
It's been quite sometime since 5.2 was branched and looking over
our "todo" majority of planned changes were made. Therefor I'd
like to make an RC1 on Thursday next week and start the
stabilization cycle of 5.2, so we can get a final in about 2
months. Once we start stabilization cycle, no new features will
be accepted, so please use this week to commit any missing new
features or major patches that have been agreed upon and not yet
applied.This caught be a bit by surprise as I was unavailabe the last two
weeks, so I hope I am still in time with my todo items (enabling
ext/date finally, and adding ext/filter with a symlink).
It seems that you are constantly and permanently do whatever you want.
That has to change.
We never agreed to enable all date classes and functions. The TODO,
online and approved since weeks, only mention date_sun_info and nothing
else.
Please revert before the first RC.
We have to solve this issue but in a reasonable and timed way, not with
your own and unilateral decisions.
Cheers,
-- Pierre
The date extension functionality can be enabled, but we need to
rename the date class to avoid naming conflicts encountered with PHP
5.1. There have been two names under consideration datetime and
phpdate. Personally I'd prefer datetime, but after doing a quick
search on google that seems like a popular name, already being used
in various classes and libraries. phpdate (or PHPDate to comply with
studly caps conventions ;-) ) on the otherhand is only used a very
small number of times is minor classes therefor seems like a safe name.
If you chose PHPDate is the class name, I would no objections to
including the functionality, assuming there are no technical merits
for not including the extension.
Ilia Alshanetsky wrote:
It's been quite sometime since 5.2 was branched and looking over
our "todo"
majority of planned changes were made. Therefor I'd like to make
an RC1 on
Thursday next week and start the stabilization cycle of 5.2, so
we can get a
final in about 2 months. Once we start stabilization cycle, no
new features
will be accepted, so please use this week to commit any missing
new features
or major patches that have been agreed upon and not yet applied.This caught be a bit by surprise as I was unavailabe the last two
weeks,
so I hope I am still in time with my todo items (enabling ext/date
finally, and adding ext/filter with a symlink).Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org--
Ilia Alshanetsky
The date extension functionality can be enabled, but we need to
rename the date class to avoid naming conflicts encountered with PHP
5.1.
Wait, you are suggesting to enable this empty class and rename it? And
then he will rename it again for phph6? That's plain stupid and
insane.
I see again only one choice, enable the functions and disable the
class. It is still not what we planed since months for 5.2, but it is
the less problematic solutions.
Any other decisions should not be take in the hurry while releasing 5.2.
--Pierre
The date extension functionality can be enabled, but we need to
rename the date class to avoid naming conflicts encountered with PHP
5.1.Wait, you are suggesting to enable this empty class and rename it? And
then he will rename it again for phph6? That's plain stupid and
insane.
No. Derick wants to enable all the code in the date extension
(methods of the date class and so on). The only way I can see us
doing it is by renaming the 2 classes the extension defines to
something that won't cause namespace problems.
Ilia Alshanetsky
The date extension functionality can be enabled, but we need to
rename the date class to avoid naming conflicts encountered with PHP
5.1.Wait, you are suggesting to enable this empty class and rename it? And
then he will rename it again for phph6? That's plain stupid and
insane.No. Derick wants to enable all the code in the date extension
(methods of the date class and so on). The only way I can see us
doing it is by renaming the 2 classes the extension defines to
something that won't cause namespace problems.
Hate to be a pain, but what namespace problems? Where were all those bug
reports the first time this was enabled? Why hasn't Date in PEAR changed its
name to include the PEAR prefix? Aren't these 'namespace problems' so much
vaporware?
- Steph
Ilia Alshanetsky
The date extension functionality can be enabled, but we need to
rename the date class to avoid naming conflicts encountered with PHP
5.1. There have been two names under consideration datetime and
phpdate. Personally I'd prefer datetime, but after doing a quick
search on google that seems like a popular name, already being used
in various classes and libraries. phpdate (or PHPDate to comply with
studly caps conventions ;-) ) on the otherhand is only used a very
small number of times is minor classes therefor seems like a safe
name.If you chose PHPDate is the class name, I would no objections to
including the functionality, assuming there are no technical merits
for not including the extension.Ilia Alshanetsky wrote:
It's been quite sometime since 5.2 was branched and looking over
our "todo"
majority of planned changes were made. Therefor I'd like to make
an RC1 on
Thursday next week and start the stabilization cycle of 5.2, so
we can get a
final in about 2 months. Once we start stabilization cycle, no
new features
will be accepted, so please use this week to commit any missing
new features
or major patches that have been agreed upon and not yet applied.This caught be a bit by surprise as I was unavailabe the last two
weeks,
so I hope I am still in time with my todo items (enabling ext/date
finally, and adding ext/filter with a symlink).Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org--
Ilia Alshanetsky
It'd be nice to have a php namespace, wouldn't it? ;)
Maybe you might not want to include that class until PHP6. Or, how
about for backwards compatibility, you do prefix the class name with
PHP, but when namespaces come into play, using the php namespace
effectively removes the PHP prefix (e.g. PHPDate == php::Date).
Matt Sicker
It'd be nice to have a php namespace, wouldn't it? ;)
And that would help... how?
Two classes named "Date" will still clash, namespaces won't magically solve it.
Maybe you might not want to include that class until PHP6. Or, how
about for backwards compatibility, you do prefix the class name with
PHP, but when namespaces come into play, using the php namespace
effectively removes the PHP prefix (e.g. PHPDate == php::Date).
--
Wbr,
Antony Dovgal
Maybe you might not want to include that class until PHP6. Or, how
about for backwards compatibility, you do prefix the class name with
PHP, but when namespaces come into play, using the php namespace
effectively removes the PHP prefix (e.g. PHPDate == php::Date).
If you rename it later it will definitely break at that moment, so
that's a no-no.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
Maybe you might not want to include that class until PHP6. Or, how
about for backwards compatibility, you do prefix the class name
with PHP, but when namespaces come into play, using the php
namespace effectively removes the PHP prefix (e.g. PHPDate ==
php::Date).If you rename it later it will definitely break at that moment, so
that's a no-no.Derick
What I'm suggesting is that for PHP6, allow namespaces to be used in two
different ways. Example:
namespace foo {
class bar {
private $baz;
static private $oof = 0;
function __construct($baz) {
$this->baz = $baz;
$this->oof++; # I don't remember if you can do this, but you get
# the idea
}
static function getOof() {
return $this->oof;
}
}
}
Then, we can access class `bar' like so:
$bar = new foo::bar('e.g.');
$oof = foo_bar::getOOf();
Or, you might just remove the underscore altogether so that we can
introduce more useful namespaces (e.g. all the DOM classes can go in
the DOM namespace). Perhaps you could use the underscore for functions
(!methods), thus also allowing many functions to be given their own
namespaces (e.g. mysql_connect() == mysql::connect()).
Now since you would be able to declare something like:
using namespace mysql;
You'd be able to access its functions like so:
$db = connect('localhost', 'username', 'password') or
die(header('HTTP/1.1 500 Internal Service Error'));
Now that might not be a good example considering mysql_* is old and
crappy, and since using a mysqli example would be redundant since it
already has a class, well, you know...
Anyhow, any feedback on this? Or should I post this separately to get
feedback since it regards PHP6?
Matt Sicker
I will just warn you that task 17 is assigned to no one but it seems it is
quite easy to be done.
I will just warn you that task 17 is assigned to no one but it seems it is
quite easy to be done.
It is, to someone with a shell access :)
Also after I got a german "translation", it seems that Marcus was
talking about the README_UPGRADE file and not the TODO, go figure...
--Pierre