Re: [PHP-DEV] [RFC] Release Process
Hi, On Mon, 2010-11-22 at 23:21 -0200, Felipe Pena wrote: With the recent chaos in the way we begin and ended releases, we would like to propose a clean way to deal with releases and related decisions: [1] Thanks for preparing this. I have one change proposal: With the proposed model it might, as you have illustrated, happen that there are 5 versions being maintained. As I mentioned multiple times on this list, on irc and other places I like a Ubuntu-like model with two kinds of release which I, for the purpose of this discussion, call early access (EA) and long term supported (LTS) version. At any given time only one EA may exist. When a new LTS version is being released the previous LTS version enters security-only mode to give users a transition period. Between every LTS version there are two EA versions. 20112012 2013 201420152016 2017 | | | | | | | | | | | | | LTS1+---D | | | | EA1 | | D | | | | | | | | EA2 | | | | D | | | | | | LTS2| | | | | | ---D EA3 | | | | | | | | D EA4 | | | | | | | | | | D The benefit is that developers and users who require a specific feature get it early while distributors/hosters/software vendors/... have a safe bet. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] --enable-zend-multibyte
hi,
I've prepared the patch which completely removes compile-time
--enable-zend-multibyte configuration directive.
The configuration can be changed at run-tume using zend.multibyte=0/1.
The patch also fixes Unicode detection for phar archives.
I would like to commit it on Thursday.
Thanks. Dmitry.
Index: ext/standard/info.c
===
--- ext/standard/info.c (revision 305647)
+++ ext/standard/info.c (working copy)
@@ -759,11 +759,7 @@
php_info_print_table_row(2, Zend Memory Manager,
is_zend_mm(TSRMLS_C) ? enabled : disabled );
-#ifdef ZEND_MULTIBYTE
- php_info_print_table_row(2, Zend Multibyte Support,
enabled);
-#else
- php_info_print_table_row(2, Zend Multibyte Support,
disabled);
-#endif
+ php_info_print_table_row(2, Zend Multibyte Support,
CG(multibyte) ? enabled : disabled);
#if HAVE_IPV6
php_info_print_table_row(2, IPv6 Support, enabled );
Index: ext/phar/tests/zip/notphar.phpt
===
--- ext/phar/tests/zip/notphar.phpt (revision 305647)
+++ ext/phar/tests/zip/notphar.phpt (working copy)
@@ -4,6 +4,7 @@
?php if (!extension_loaded(phar)) die(skip); ?
--INI--
phar.readonly=1
+detect_unicode=0
--FILE--
?php
$fname = dirname(__FILE__) . '/' . basename(__FILE__, '.php') . '.phar.zip';
Index: ext/mbstring/tests/zend_multibyte-10.phpt
===
--- ext/mbstring/tests/zend_multibyte-10.phpt (revision 305647)
+++ ext/mbstring/tests/zend_multibyte-10.phpt (working copy)
@@ -11,6 +11,7 @@
?php
declare(encoding=ISO-8859-15);
declare(encoding=ISO-8859-1);
+echo ok\n;
?
--EXPECTF--
-Fatal error: Encoding declaration pragma must be the very first statement in
the script in %s on line 3
+ok
Index: ext/mbstring/tests/zend_multibyte-11.phpt
===
--- ext/mbstring/tests/zend_multibyte-11.phpt (revision 305647)
+++ ext/mbstring/tests/zend_multibyte-11.phpt (working copy)
@@ -11,7 +11,8 @@
?php
declare(encoding=ISO-8859-15) {
declare(encoding=ISO-8859-1);
+ echo ok\n;
}
?
--EXPECTF--
-Fatal error: Encoding declaration pragma must be the very first statement in
the script in %s on line 3
+ok
Index: ext/mbstring/mbstring.c
===
--- ext/mbstring/mbstring.c (revision 305647)
+++ ext/mbstring/mbstring.c (working copy)
@@ -77,9 +77,7 @@
#include php_mbregex.h
#endif
-#ifdef ZEND_MULTIBYTE
#include zend_multibyte.h
-#endif /* ZEND_MULTIBYTE */
#if HAVE_ONIG
#include php_onig_compat.h
@@ -98,12 +96,10 @@
static PHP_GINIT_FUNCTION(mbstring);
static PHP_GSHUTDOWN_FUNCTION(mbstring);
-#ifdef ZEND_MULTIBYTE
static size_t php_mb_oddlen(const unsigned char *string, size_t length, const
char *encoding TSRMLS_DC);
static int php_mb_encoding_converter(unsigned char **to, size_t *to_length,
const unsigned char *from, size_t from_length, const char *encoding_to, const
char *encoding_from TSRMLS_DC);
static char* php_mb_encoding_detector(const unsigned char *arg_string, size_t
arg_length, char *arg_list TSRMLS_DC);
static int php_mb_set_zend_encoding(TSRMLS_D);
-#endif
/* }}} */
/* {{{ php_mb_default_identify_list */
@@ -1126,12 +1122,14 @@
}
/* }}} */
-#ifdef ZEND_MULTIBYTE
/* {{{ static PHP_INI_MH(OnUpdate_mbstring_script_encoding) */
static PHP_INI_MH(OnUpdate_mbstring_script_encoding)
{
int *list, size;
+ if (!CG(multibyte)) {
+ return FAILURE;
+ }
if (php_mb_parse_encoding_list(new_value, new_value_length, list,
size, 1 TSRMLS_CC)) {
if (MBSTRG(script_encoding_list) != NULL) {
free(MBSTRG(script_encoding_list));
@@ -1150,7 +1148,6 @@
return SUCCESS;
}
/* }}} */
-#endif /* ZEND_MULTIBYTE */
/* {{{ static PHP_INI_MH(OnUpdate_mbstring_substitute_character) */
static PHP_INI_MH(OnUpdate_mbstring_substitute_character)
@@ -1249,9 +1246,7 @@
PHP_INI_ENTRY(mbstring.http_input, pass, PHP_INI_ALL,
OnUpdate_mbstring_http_input)
PHP_INI_ENTRY(mbstring.http_output, pass, PHP_INI_ALL,
OnUpdate_mbstring_http_output)
STD_PHP_INI_ENTRY(mbstring.internal_encoding, NULL, PHP_INI_ALL,
OnUpdate_mbstring_internal_encoding, internal_encoding_name,
zend_mbstring_globals, mbstring_globals)
-#ifdef ZEND_MULTIBYTE
PHP_INI_ENTRY(mbstring.script_encoding, NULL, PHP_INI_ALL,
OnUpdate_mbstring_script_encoding)
-#endif /* ZEND_MULTIBYTE */
PHP_INI_ENTRY(mbstring.substitute_character, NULL, PHP_INI_ALL,
OnUpdate_mbstring_substitute_character)
STD_PHP_INI_ENTRY(mbstring.func_overload, 0,
PHP_INI_SYSTEM, OnUpdateLong, func_overload, zend_mbstring_globals,
mbstring_globals)
@@ -1278,10 +1273,8 @@
mbstring_globals-language =
Re: [PHP-DEV] Hold off 5.4
2010/11/23 Felipe Pena felipe...@gmail.com:
Given the current state of trunk, I think 5.4 release process should
not begin tomorrow (alpha or whatever other status). There are
numerous identified issues that we need to fix before even think to
begin with a release. For example:
- type hinting (or strict hinting)
- no consensus
- the RFCs are unclear
- BC break introduced
. classes named as any of the type hint scalar types
do not work anymore
aka class int {}
- Traits may not be ready yet for pre-release
- see http://svn.php.net/viewvc?view=revisionrevision=298348
- APC support
- There are many changes not BC with 5.x, as we allowed them for the
development tree, before 5.4 was even a topic
- APC is not yet bundled. Having the opcode bundle can raise issues by
one or another, we should have it in from the very 1st release
- pecl/http was planned to be bundled. What's the status?
We also have no plan about what will or will not be 5.4. This looks
familiar, this is exactly how we begun 5.3 and it tooks literally
years to be released. There is also actually no agreement to begin
with 5.4 now.
5.4 should be hold off until we solved the listed issues and the
release management RFC gets discussed and hopefully approved.
Thanks.
--
Regards,
Felipe Pena
Nor do we have a clear roadmap concerning the removal of magic quotes!
Most would like to get rid of them, but some have concerns about doing
it in 5.4.
(Please, use the Magic quotes in trunk thread to comment on this
one: http://news.php.net/php.internals/50301)
--
Patrick Allaert
---
http://code.google.com/p/peclapm/ - Alternative PHP Monitor
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hold off 5.4
Hi: On 23 Nov 2010, at 02:30, Felipe Pena wrote: - Traits may not be ready yet for pre-release - see http://svn.php.net/viewvc?view=revisionrevision=298348 The listed todos where: - Reflection API That was implemented by Johannes as far as I remember. - support for traits for internal classes - currently destroy_zend_class does not handle that case For support of internal classes was no clear interest yet, so it never got done. Is that a show stopper? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hold off 5.4
Am 23.11.2010 02:30, schrieb Felipe Pena: classes named as any of the type hint scalar types do not work anymore Was it not a promise of the re2c/lemon migration to allow reserved words as class/function names? -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hold off 5.4
On Tue, Nov 23, 2010 at 10:35 AM, Patrick ALLAERT patrickalla...@php.netwrote:
2010/11/23 Felipe Pena felipe...@gmail.com:
Given the current state of trunk, I think 5.4 release process should
not begin tomorrow (alpha or whatever other status). There are
numerous identified issues that we need to fix before even think to
begin with a release. For example:
- type hinting (or strict hinting)
- no consensus
- the RFCs are unclear
- BC break introduced
. classes named as any of the type hint scalar types
do not work anymore
aka class int {}
- Traits may not be ready yet for pre-release
- see http://svn.php.net/viewvc?view=revisionrevision=298348
- APC support
- There are many changes not BC with 5.x, as we allowed them for the
development tree, before 5.4 was even a topic
- APC is not yet bundled. Having the opcode bundle can raise issues by
one or another, we should have it in from the very 1st release
- pecl/http was planned to be bundled. What's the status?
We also have no plan about what will or will not be 5.4. This looks
familiar, this is exactly how we begun 5.3 and it tooks literally
years to be released. There is also actually no agreement to begin
with 5.4 now.
5.4 should be hold off until we solved the listed issues and the
release management RFC gets discussed and hopefully approved.
Thanks.
--
Regards,
Felipe Pena
Nor do we have a clear roadmap concerning the removal of magic quotes!
Most would like to get rid of them, but some have concerns about doing
it in 5.4.
(Please, use the Magic quotes in trunk thread to comment on this
one: http://news.php.net/php.internals/50301)
And not just the magic quotes:
http://www.pubbs.net/201011/php/28851-re-php-dev-magic-quotes-in-trunk.html
with the current trunk, we dropped many deprecated legacy feature, which is
nice, but breaks bc with a minor version.
So I would favor a more sophisticated development and release
policy/standard.
and the current release is a good example why this is needed:
first Rasmus and others said, that we shouldn't plan beforehand the next
release, just start coding, and when we have enough staff, we can discuss
and vote on the version number, release managers, what will be included in
the release.
then after some time, magically the RM's were selected (I didn't see the
voting, maybe it happened via irc), and the 5.4 was selected for the next
version without vote (maybe irc...), and there were selected a few change
from the trunk for discussion, the most of them was included to the release
without formal approval.
:/
Tyrael
Re: [PHP-DEV] Hold off 5.4
On Mon, 22 Nov 2010, Felipe Pena wrote:
Given the current state of trunk, I think 5.4 release process should
not begin tomorrow (alpha or whatever other status). There are
numerous identified issues that we need to fix before even think to
begin with a release. For example:
- type hinting (or strict hinting)
- no consensus
- the RFCs are unclear
- BC break introduced
. classes named as any of the type hint scalar types
do not work anymore
aka class int {}
Yeah, there is a slight hint of a BC break in case you have a class
named int or float etc. But there is:
http://uk.php.net/manual/en/userlandnaming.tips.php
Perhaps we can reduce the current list of classes:
int, integer, real, double, string, binary, scalar, array, object,
bool, boolean
to what the manual uses though (for prototypes):
int, float, string, binary, scalar, array, object, bool
(Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php)
- Traits may not be ready yet for pre-release
- see http://svn.php.net/viewvc?view=revisionrevision=298348
- APC support
I don't see why this can't be done after post-branching/post-alpha1
- There are many changes not BC with 5.x, as we allowed them for the
development tree, before 5.4 was even a topic
What's the list?
- APC is not yet bundled. Having the opcode bundle can raise issues by
one or another, we should have it in from the very 1st release
Bundling it is a question of copying it over. It compiles, although I am
not 100% whether it works. If it doesn't fit in the end in the timeline,
we can always remove it again as it's a standalone extension.
- pecl/http was planned to be bundled. What's the status?
I'm all for it; but again, it's just copying it over to trunk before we
branch.
We also have no plan about what will or will not be 5.4. This looks
familiar, this is exactly how we begun 5.3 and it tooks literally
years to be released. There is also actually no agreement to begin
with 5.4 now.
Yes, but instead of defining what is PHP 5.4, why not just go with
what we have? Everything that's not in thre is for PHP-next-next again.
5.4 should be hold off until we solved the listed issues and the
release management RFC gets discussed and hopefully approved.
Why do you need a release management RFC? We've made releases for more
than a decade just fine.
Stalling every time doesn't get us anywhere. IMO we should just go with
it. Which means as a rough guide:
- copy over APC/pecl_http
- branch on thursday
- alpha next week
- build a list of things that needs doing in 5.4 to get it ready (with
possible options to get rid of apc/pecl_http if they are not up to
date enough)
I am absolutely against stalling again!
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] --enable-zend-multibyte
On Tue, 23 Nov 2010, Dmitry Stogov wrote: I've prepared the patch which completely removes compile-time --enable-zend-multibyte configuration directive. The configuration can be changed at run-tume using zend.multibyte=0/1. The patch also fixes Unicode detection for phar archives. I would like to commit it on Thursday. Pending branching on Thursday, perhaps you should commit it tomorrow instead? The patch looks pretty clean! cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] --enable-zend-multibyte
Derick Rethans wrote: On Tue, 23 Nov 2010, Dmitry Stogov wrote: I've prepared the patch which completely removes compile-time --enable-zend-multibyte configuration directive. The configuration can be changed at run-tume using zend.multibyte=0/1. The patch also fixes Unicode detection for phar archives. I would like to commit it on Thursday. Pending branching on Thursday, perhaps you should commit it tomorrow instead? The patch looks pretty clean! I would do it right now. :) OK, lets wait till tomorrow. At least I didn't hear serious objections about previous patch and several requests to remove --enable-zend-multibyte completely. Thanks. Dmitry. cheers, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hold off 5.4
Am 23.11.2010 10:57, schrieb Derick Rethans: I am absolutely against stalling again! +1 If there is anything that needs particular TLC (testing/loving/care), let me know. FYI, at the moment I am playing a lot with traits to get a(n updated) feel for them. -- Sebastian BergmannCo-Founder and Principal Consultant http://sebastian-bergmann.de/ http://thePHP.cc/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Release Process
On Mon, 22 Nov 2010, Felipe Pena wrote: With the recent chaos in the way we begin and ended releases, we would like to propose a clean way to deal with releases and related decisions: [1] Really? I think you're blowing this all way out of proportion. I don't mind a yearly release cycle, as we should get out more releases. I don't mind a monthly release cycle for .z releases. What however goes straight against this is: * January o Decisions which features or changes will be in the next release You don't decide on it, you just have to go with what we have. All the rest you write in the RFC is basically already as we do it. regards, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] --enable-zend-multibyte
On Tue, 23 Nov 2010 09:34:49 -, Dmitry Stogov dmi...@zend.com wrote: hi, I've prepared the patch which completely removes compile-time --enable-zend-multibyte configuration directive. The configuration can be changed at run-tume using zend.multibyte=0/1. The patch also fixes Unicode detection for phar archives. I would like to commit it on Thursday. Just two comments: * You have a line commented out with // (line #443) * The phar fix autodetection is wrong. You look for __HALT_COMPILER, but you should be looking for __HALT_COMPILER();, __halt_compiler(); or any casing variation. __HALT_COMPILER, by itself, does nothing (see http://lxr.php.net/opengrok/xref/PHP_TRUNK/Zend/zend_language_parser.y#219 ). See the patches in #53199. Also remember to close #42396 once you commit a proper fix. Other than that, no objections. -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] --enable-zend-multibyte
Gustavo Lopes wrote: On Tue, 23 Nov 2010 09:34:49 -, Dmitry Stogov dmi...@zend.com wrote: hi, I've prepared the patch which completely removes compile-time --enable-zend-multibyte configuration directive. The configuration can be changed at run-tume using zend.multibyte=0/1. The patch also fixes Unicode detection for phar archives. I would like to commit it on Thursday. Just two comments: * You have a line commented out with // (line #443) * The phar fix autodetection is wrong. You look for __HALT_COMPILER, but you should be looking for __HALT_COMPILER();, __halt_compiler(); or any casing variation. __HALT_COMPILER, by itself, does nothing (see http://lxr.php.net/opengrok/xref/PHP_TRUNK/Zend/zend_language_parser.y#219 ). See the patches in #53199. Thank you for comments. I'll care about both issues. Thanks. Dmitry. Also remember to close #42396 once you commit a proper fix. Other than that, no objections. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hold off 5.4
On Tue, 2010-11-23 at 10:51 +0100, Stefan Marr wrote: On 23 Nov 2010, at 02:30, Felipe Pena wrote: - Traits may not be ready yet for pre-release - see http://svn.php.net/viewvc?view=revisionrevision=298348 The listed todos where: - Reflection API That was implemented by Johannes as far as I remember. That is not 100% complete. I had an issue with Aliases and finding the original declaration or such. Will be done before we reach beta. - support for traits for internal classes - currently destroy_zend_class does not handle that case For support of internal classes was no clear interest yet, so it never got done. Is that a show stopper? Can Traits be declared internally and the issue is only about using them? I think we can live without using traits for internal classes easily (as we can already do that by aliasing the methods internally ;-) ) Being able to provide traits might be interesting, but I don't see it as high priority task. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hold off 5.4
On Tue, 2010-11-23 at 10:55 +0100, Ferenc Kovacs wrote: and the 5.4 was selected for the next version without vote (maybe irc...) As we are not marketing-driven version numbers follow technical reasoning. There's no larger BC break (like a radical change in the object model like from 4 to 5) and no radical change to the string type (like from PHP 5 to PHP-Unicode) there's nothing to discuss about. :-) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hold off 5.4
We also have no plan about what will or will not be 5.4. This looks familiar, this is exactly how we begun 5.3 and it tooks literally years to be released. There is also actually no agreement to begin with 5.4 now. Yes, but instead of defining what is PHP 5.4, why not just go with what we have? Everything that's not in thre is for PHP-next-next again. backward compatibility™ we had a few nice things in the PHP6 branch, which got merged into the trunk, before choosing the version number for the trunk. it's okay, but we agreed on that if that gets into the trunk, that it doesn't mean, that it will be shipped automatically with the next release. you can read again the fuss about the scalar type hinting: after a release, we start to think trunk as a development branch, where everything can get in: At 18:04 22/05/2010, Pierre Joye wrote: hi Zeev, It seems that there was a bit of discussions on IRC about committing Ilia's implementation. However it is trunk, and trunk is a development tree. That means its purpose is to develop new PHP features. But it does not meant that these features will make it in the next releases or if they will remain as they are now. but when we start to roll out a release, laziness/eagerness kicks in, and we start rambling about status quo (if it's in the trunk, then its ready to go). On Sat, May 22, 2010 at 11:10 AM, Zeev Suraski z...@zend.com wrote: Maybe I view trunk in a different way than others, but I think committing it turns it into some sort of 'status quo', and now we'd need a good reason to change it. And after all those discussion about the past and current scalar type hints, here they are: they are planned to be released, without consensus, and the current implementation doesn't even the same, that we talked our ass off about. :/ 5.4 should be hold off until we solved the listed issues and the release management RFC gets discussed and hopefully approved. Why do you need a release management RFC? We've made releases for more than a decade just fine. yeah, but the current situation is a little bit different(we have code in the trunk which was intended for 6.0, where bc isn't a problem at all), than the previous ones. and I think we can't say that there are room for improvements about the current lackoff release policies. hell, we don't even agree on things like what is the status of the code in trunk(can we commit without consensus, or do we decide about it before the release), or what are the rules for the versioning schema(which version is allowed to break what). :/ Stalling every time doesn't get us anywhere. IMO we should just go with it. I am absolutely against stalling again! I am too, but I think that we should carefully cherrypick, what to release with 5.4 from the current trunk. Tyrael
RE: [PHP-DEV] Hold off 5.4
-Original Message-
From: Derick Rethans [mailto:der...@php.net]
Sent: Tuesday, November 23, 2010 11:58 AM
To: Felipe Pena
Cc: internals
Subject: Re: [PHP-DEV] Hold off 5.4
On Mon, 22 Nov 2010, Felipe Pena wrote:
Given the current state of trunk, I think 5.4 release process should
not begin tomorrow (alpha or whatever other status). There are
numerous identified issues that we need to fix before even think to
begin with a release. For example:
- type hinting (or strict hinting)
- no consensus
- the RFCs are unclear
- BC break introduced
. classes named as any of the type hint scalar types do not work
anymore aka class int {}
Yeah, there is a slight hint of a BC break in case you have a class named
int
or float etc. But there is:
http://uk.php.net/manual/en/userlandnaming.tips.php
For the record, I'm still very uncomfortable with this new language syntax -
even if it's a no-op right now.
How do we document it? As what?
Are we effectively going to create the original type checking implementation,
but in a separate component people would have to install - thereby creating two
very different flavors of PHP?
Regarding the alpha release, I think there are two key issues here:
1. Does this alpha mean anything at all. Some, myself included, don't feel
comfortable about the state of certain things in the current codebase (example
given above). Are we all in sync that even if a certain feature makes it into
the alpha, it doesn't mean that it won't be removed or be severely modified in
an upcoming beta/GA? Is it clear it has no implications on when the final
release would be? That is, at least, the way I perceive alpha releases. In
which case it's not exactly clear to me what the benefits of releasing an Alpha
in this day and age for PHP - where we have snapshots every few hours. We need
to have a very clear understanding of what this does or doesn't mean, and make
sure we communicate it properly to the users.
2. Not strictly related to this particular 5.4 effort, but I think that
recent months have shown that we desperately need a decision making process.
Somewhat more formalized and logical than anybody who happens to be subscribed
to internals@ being able to put things to a vote and vote on them. This is one
tough cookie - but I think we have to tackle it. My personal belief is that
people on internals@ are biased towards the very top end of the userbase
pyramid, and we have to find a way to represent the views of the PHP userbase
at large.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Release Process
On Tue, Nov 23, 2010 at 11:07 AM, Derick Rethans der...@php.net wrote: On Mon, 22 Nov 2010, Felipe Pena wrote: With the recent chaos in the way we begin and ended releases, we would like to propose a clean way to deal with releases and related decisions: [1] Really? I think you're blowing this all way out of proportion. Why do you think that? I can see two reason: 1) you think that the current rules/policies/methods are good enough. 2) you think that these rules/policies/methods aren't important for the quality of the release. both seems wrong from the past experiences of new php major/major.minor releases. see my last email in the other thread I don't mind a yearly release cycle, as we should get out more releases. I don't mind a monthly release cycle for .z releases. What however goes straight against this is: * January o Decisions which features or changes will be in the next release You don't decide on it, you just have to go with what we have. who decided that? All the rest you write in the RFC is basically already as we do it. yeah, maybe, but they aren't written down, accepted and well-known rules, so you can forgot/misunderstand/bend them. :/ Tyrael
Re: [PHP-DEV] Hold off 5.4
On Tue, Nov 23, 2010 at 12:24 PM, Zeev Suraski z...@zend.com wrote:
-Original Message-
From: Derick Rethans [mailto:der...@php.net]
Sent: Tuesday, November 23, 2010 11:58 AM
To: Felipe Pena
Cc: internals
Subject: Re: [PHP-DEV] Hold off 5.4
On Mon, 22 Nov 2010, Felipe Pena wrote:
Given the current state of trunk, I think 5.4 release process should
not begin tomorrow (alpha or whatever other status). There are
numerous identified issues that we need to fix before even think to
begin with a release. For example:
- type hinting (or strict hinting)
- no consensus
- the RFCs are unclear
- BC break introduced
. classes named as any of the type hint scalar types do not work
anymore aka class int {}
Yeah, there is a slight hint of a BC break in case you have a class named
int
or float etc. But there is:
http://uk.php.net/manual/en/userlandnaming.tips.php
For the record, I'm still very uncomfortable with this new language syntax
- even if it's a no-op right now.
How do we document it? As what?
Johannes wrote a blogpost about that:
http://schlueters.de/blog/archives/148-More-on-scalar-type-hints-in-PHP-trunk.html
and we didn't even discussed the current implementations, because the
discussion was halted until the new revised patch is complete.
which seems will be rolled out without further discussion.
Are we effectively going to create the original type checking
implementation, but in a separate component people would have to install -
thereby creating two very different flavors of PHP?
Regarding the alpha release, I think there are two key issues here:
1. Does this alpha mean anything at all. Some, myself included, don't
feel comfortable about the state of certain things in the current codebase
(example given above). Are we all in sync that even if a certain feature
makes it into the alpha, it doesn't mean that it won't be removed or be
severely modified in an upcoming beta/GA? Is it clear it has no
implications on when the final release would be? That is, at least, the way
I perceive alpha releases. In which case it's not exactly clear to me what
the benefits of releasing an Alpha in this day and age for PHP - where we
have snapshots every few hours. We need to have a very clear understanding
of what this does or doesn't mean, and make sure we communicate it properly
to the users.
we shouldn't release something, that at least the core devs are agree on.
imo.
2. Not strictly related to this particular 5.4 effort, but I think that
recent months have shown that we desperately need a decision making process.
Somewhat more formalized and logical than anybody who happens to be
subscribed to internals@ being able to put things to a vote and vote on
them. This is one tough cookie - but I think we have to tackle it. My
personal belief is that people on internals@ are biased towards the very
top end of the userbase pyramid, and we have to find a way to represent the
views of the PHP userbase at large.
Agree.
But I think that there are more than one kind of voting that we need.
- what does the avarage php user thinks about something. (adding/removing a
feature, who would use that, php.net redesign, etc.).
- what does the cms/framework dev people think about something (there are
many feature, which didn't useful directly to the end-users, but they can
get good use of it through a framework: late static binding, namespaces,
annotations, etc.)
- what does our vendors think about something (debian, redhat, etc. they can
provide useful feedback about configuration/maintenance, release policy kind
of polls)
- what does a php contributor(documentation, qa, website, etc. so involved
in the php project) thinks about something (for example polls about our
infrastructures, or standards, etc.)
- what does a pecl contributor thinks about something (adding a new hook
into the core, etc., changing internal API, etc.)
- what does a php-src contributor thinks about something (hardcore stuff,
adding new features by design/performance/maintainability wise, etc. )
and maybe it would be a good idea to restrict the poll/vote for the active
members.
so if somebody was once involved in the project, but lost time or interest,
and didn't followed or contributed to that part of the project, that those
people to bias the vote without a good understanding about the actual
problem/situation.
but of course that's only my 2 cents.
Tyrael
Re: [PHP-DEV] Hold off 5.4
On 11/23/2010 10:57 AM, Derick Rethans wrote: On Mon, 22 Nov 2010, Felipe Pena wrote: - pecl/http was planned to be bundled. What's the status? I'm all for it; but again, it's just copying it over to trunk before we branch. ... - copy over APC/pecl_http - branch on thursday - alpha next week - build a list of things that needs doing in 5.4 to get it ready (with possible options to get rid of apc/pecl_http if they are not up to date enough) Huh? I'm quite surprised to read that pecl/http is planned to be bundled with trunk, while--sure--my grand master plan included this option, there's only pecl/http/branches/DEV_2 which is compatible with trunk and I doubt you all are talking about that version? It still needs some serious amount of work, development has stalled again due to my job's demands. Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Hold off 5.4
On 11/23/2010 02:30 AM, Felipe Pena wrote: Given the current state of trunk, I think 5.4 release process should not begin tomorrow (alpha or whatever other status). There are numerous identified issues that we need to fix before even think to begin with a release. For example: ... We also have no plan about what will or will not be 5.4. This looks familiar, this is exactly how we begun 5.3 and it tooks literally years to be released. There is also actually no agreement to begin with 5.4 now. 5.4 should be hold off until we solved the listed issues and the release management RFC gets discussed and hopefully approved. +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hold off 5.4
On Tue, 23 Nov 2010, Michael Wallner wrote: On 11/23/2010 10:57 AM, Derick Rethans wrote: On Mon, 22 Nov 2010, Felipe Pena wrote: - pecl/http was planned to be bundled. What's the status? I'm all for it; but again, it's just copying it over to trunk before we branch. ... - copy over APC/pecl_http - branch on thursday - alpha next week - build a list of things that needs doing in 5.4 to get it ready (with possible options to get rid of apc/pecl_http if they are not up to date enough) Huh? I'm quite surprised to read that pecl/http is planned to be bundled with trunk, while--sure--my grand master plan included this option, there's only pecl/http/branches/DEV_2 which is compatible with trunk and I doubt you all are talking about that version? Nope; I wasn't. But fine then, we don't bundle it :-) Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hold off 5.4
On Tue, 23 Nov 2010, Ferenc Kovacs wrote: We also have no plan about what will or will not be 5.4. This looks familiar, this is exactly how we begun 5.3 and it tooks literally years to be released. There is also actually no agreement to begin with 5.4 now. Yes, but instead of defining what is PHP 5.4, why not just go with what we have? Everything that's not in thre is for PHP-next-next again. backward compatibility™ we had a few nice things in the PHP6 branch, which got merged into the trunk, before choosing the version number for the trunk. Do you have a list? Stalling every time doesn't get us anywhere. IMO we should just go with it. I am absolutely against stalling again! I am too, but I think that we should carefully cherrypick, what to release with 5.4 from the current trunk. Cherry pick? Do you have any idea how complicated that is? Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Release Process
On Tue, 23 Nov 2010, Ferenc Kovacs wrote: All the rest you write in the RFC is basically already as we do it. yeah, maybe, but they aren't written down, accepted and well-known rules, so you can forgot/misunderstand/bend them. :/ And I don't think that is a bad thing. It's good to be able to be flexible. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Hold off 5.4
On Tue, 23 Nov 2010, Zeev Suraski wrote:
On Tue, 23 Nov 2010, Derick Rethans wrote:
On Mon, 22 Nov 2010, Felipe Pena wrote:
Given the current state of trunk, I think 5.4 release process should
not begin tomorrow (alpha or whatever other status). There are
numerous identified issues that we need to fix before even think to
begin with a release. For example:
- type hinting (or strict hinting)
- no consensus
- the RFCs are unclear
- BC break introduced
. classes named as any of the type hint scalar types do not work
anymore aka class int {}
Yeah, there is a slight hint of a BC break in case you have a class named
int
or float etc. But there is:
http://uk.php.net/manual/en/userlandnaming.tips.php
For the record, I'm still very uncomfortable with this new language
syntax - even if it's a no-op right now.
I know you are; but from what I understood, there were no more comments
to the latest mail (with patch and RFC) that I've made towards this.
I'm not comfortable about not having the proper strict checks that we
had. It seems we're both having to live with something uncomfortable.
Are we effectively going to create the original type checking
implementation, but in a separate component people would have to
install - thereby creating two very different flavors of PHP?
It's clearly a debugging aid for me. So this should be in a debugging
extension. I doubt any sort of shared hoster would install it, but it
*does* give people the power to do this for their own controlled set-up.
Also, if the extension is suddenly not there, the app will still work so
I am not buying your two flavours argument.
Regarding the alpha release, I think there are two key issues here:
1. Does this alpha mean anything at all. Some, myself included,
don't feel comfortable about the state of certain things in the
current codebase (example given above). Are we all in sync that even
if a certain feature makes it into the alpha, it doesn't mean that it
won't be removed or be severely modified in an upcoming beta/GA?
Is it clear it has no implications on when the final release would be?
That is, at least, the way I perceive alpha releases. In which case
it's not exactly clear to me what the benefits of releasing an Alpha
in this day and age for PHP - where we have snapshots every few hours.
We need to have a very clear understanding of what this does or
doesn't mean, and make sure we communicate it properly to the users.
To me this alpha would be a this is what we're mostly likely going to
have thing. I wouldn't like to see new major features, engine rework
being done; but I also think we shouldn't try to remove stuff from it
unless really necessary.
regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hold off 5.4
On 2010-11-23, Derick Rethans der...@php.net wrote:
On Mon, 22 Nov 2010, Felipe Pena wrote:
. classes named as any of the type hint scalar types
do not work anymore
aka class int {}
Yeah, there is a slight hint of a BC break in case you have a class
named int or float etc. But there is:
http://uk.php.net/manual/en/userlandnaming.tips.php
Perhaps we can reduce the current list of classes:
int, integer, real, double, string, binary, scalar, array, object,
bool, boolean
to what the manual uses though (for prototypes):
int, float, string, binary, scalar, array, object, bool
(Point #18 at http://doc.php.net/php/dochowto/chapter-conventions.php)
Sorry, but this is actually a pretty grave BC break.
Currently, you can do the following:
namespace Foo\Validator;
class Int {}
Because of the changes proposed, this would no longer work, breaking
code that currently works with 5.3. I'd only expect a break like this
when jumping to a major version -- and even then, I'd think that adding
new keywords for such common names would need a *lot* of justification.
As Sebastian noted, it seems this should be addressed with the new
lexer; I'd argue that if the current type hinting must introduce new
keywords, it should wait until the new lexer is in place in order to
insulate end-users from such changes.
snip
We also have no plan about what will or will not be 5.4. This looks
familiar, this is exactly how we begun 5.3 and it tooks literally
years to be released. There is also actually no agreement to begin
with 5.4 now.
Yes, but instead of defining what is PHP 5.4, why not just go with
what we have? Everything that's not in thre is for PHP-next-next again.
5.4 should be hold off until we solved the listed issues and the
release management RFC gets discussed and hopefully approved.
Why do you need a release management RFC? We've made releases for more
than a decade just fine.
Stalling every time doesn't get us anywhere. IMO we should just go with
it. Which means as a rough guide:
- copy over APC/pecl_http
- branch on thursday
- alpha next week
- build a list of things that needs doing in 5.4 to get it ready (with
possible options to get rid of apc/pecl_http if they are not up to
date enough)
I am absolutely against stalling again!
I call shenanigans. This is *exactly* why a release process is desired
and necessary -- because right now, there are BC breaks in trunk, only a
vague idea about what may or may not be ready, and competing ideas about
what constitutes grounds for branching. Just go with it may work for a
few people, but that sort of attitude leaves those whose features were
skipped over or who were away from the list and/or IRC for a few days
wondering what happened later. With a defined release process,
*everyone* knows what must be done, by when, making the process more
transparent and *gasp* democratic.
--
Matthew Weier O'Phinney
Project Lead| matt...@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hold off 5.4
On Tue, 23 Nov 2010, Ferenc Kovacs wrote: and we didn't even discussed the current implementations, because the discussion was halted until the new revised patch is complete. which seems will be rolled out without further discussion. Really? You had all the opportunity to comment on either my announcement: http://thread.gmane.org/gmane.comp.php.devel/62298/focus=62510 to which Dmitry and Stas commented; as well as my mail: http://thread.gmane.org/gmane.comp.php.devel/62298/focus=62858 that annouced the third compromise implementation. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Release Process
On Tue, Nov 23, 2010 at 2:59 PM, Derick Rethans der...@php.net wrote: On Tue, 23 Nov 2010, Ferenc Kovacs wrote: All the rest you write in the RFC is basically already as we do it. yeah, maybe, but they aren't written down, accepted and well-known rules, so you can forgot/misunderstand/bend them. :/ And I don't think that is a bad thing. It's good to be able to be flexible. Derick Its good for you, but its bad for the people, who expect you to follow the rules, you know, the vendors, developers, etc. Tyrael
Re: [PHP-DEV] [RFC] Release Process
On 2010-11-23, Derick Rethans der...@php.net wrote: On Tue, 23 Nov 2010, Ferenc Kovacs wrote: All the rest you write in the RFC is basically already as we do it. yeah, maybe, but they aren't written down, accepted and well-known rules, so you can forgot/misunderstand/bend them. :/ And I don't think that is a bad thing. It's good to be able to be flexible. A good artist is capable of great flexibility within the constraints of their medium. In the case of software releases, you can still have greate flexibility even with an existing release process. In many ways, having the process defined helps bring about creative solutions -- if I want to get this in time for the release, what solution will work best? I used to love the ad hoc nature of we'll release when it's ready. However, having done quite a number of scheduled releases, I've found that: * Predictability motivates developers. Release is in 3 months? Okay, let's get rolling on this! * Knowing when the next release is coming also means that developers are more comfortable if they're unable to make the deadline. I can't do it by this release, but I should have no trouble making the next. * Less stressful for release managers. If the code isn't ready by the deadline, it's not merged to the branch, plain and simple. The status quo works great for those whom it serves. For everyone else, it stinks. There's no transparency, which leads to disenfranchisement. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Hold off 5.4
On 2010-11-23, Derick Rethans der...@php.net wrote: On Tue, 23 Nov 2010, Zeev Suraski wrote: Are we effectively going to create the original type checking implementation, but in a separate component people would have to install - thereby creating two very different flavors of PHP? It's clearly a debugging aid for me. So this should be in a debugging extension. I doubt any sort of shared hoster would install it, but it *does* give people the power to do this for their own controlled set-up. Also, if the extension is suddenly not there, the app will still work so I am not buying your two flavours argument. While the code may still work, it won't work *as* *expected*. If the PHP interpreter can execute the application, then it should provide the same output given the same input -- and this would not be the case. That's the two flavours argument. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Release Process
Just a thought from a non-dev Rules/policies/procedures/process should always be written down or recorded somewhere, otherwise how do you know what they are? and how do you make sure changes to those rules are known about? Having a central place that every can reference (wiki) makes a ton of sense. This doesn't mean they have to be inflexible. Flexibility is down to how those rules etc are written. this is fairly basic service management sort of stuff. (No i am not proposing bringing in ITIL/CMMI would be sensible) By having this sort of stuff in the wiki, you are making it easier for new people to get up to speed and reduce the arguments over what the agreed method of doing X is. James -Original Message- From: i...@tyrael.hu [mailto:tyr...@gmail.com] On Behalf Of Ferenc Kovacs Sent: 23 November 2010 14:10 To: Derick Rethans Cc: Felipe Pena; internals Subject: Re: [PHP-DEV] [RFC] Release Process On Tue, Nov 23, 2010 at 2:59 PM, Derick Rethans der...@php.net wrote: On Tue, 23 Nov 2010, Ferenc Kovacs wrote: All the rest you write in the RFC is basically already as we do it. yeah, maybe, but they aren't written down, accepted and well-known rules, so you can forgot/misunderstand/bend them. :/ And I don't think that is a bad thing. It's good to be able to be flexible. Derick Its good for you, but its bad for the people, who expect you to follow the rules, you know, the vendors, developers, etc. Tyrael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Hold off 5.4
For the record, I'm still very uncomfortable with this new language syntax - even if it's a no-op right now. I know you are; but from what I understood, there were no more comments to the latest mail (with patch and RFC) that I've made towards this. I know, I took some time off after reaching agreement we're not going to add strict checks - but I said from the get go that it's questionable whether we should add this syntax. I'm not comfortable about not having the proper strict checks that we had. Except we never had them. It's like me committing support for inline assembly syntax or whatever other weird idea I might come up with, and then saying I don't feel comfortable about removing it. With such fundamental changes there should be a very broad support, with the status-quo being the default in case no such broad support is reached. The status quo is not the latest state of trunk, but rather, the state of previous versions. It seems we're both having to live with something uncomfortable. We should attribute as much importance to adding features as removing features; Can I jump ahead and remove this support in trunk, and get back to you with 'one of us will have to feel uncomfortable' feedback? I don't think it works that way. The status quo, and the way PHP existed since forever, is no strict type checking or syntax for supporting it. IMHO before there's a clear informed decision to change that, it should stay that way. With the kind of phpdoc updates we're likely to add, you should be able to implement your extension-level support on top of this meta data. The chances of that becoming mainstream and creating two flavors of PHP are much slimmer which make it a much better fit than a big chunk of language level syntax that's a no-op by default. Are we effectively going to create the original type checking implementation, but in a separate component people would have to install - thereby creating two very different flavors of PHP? It's clearly a debugging aid for me. So this should be in a debugging extension. I doubt any sort of shared hoster would install it, but it *does* give people the power to do this for their own controlled set-up. Also, if the extension is suddenly not there, the app will still work so I am not buying your two flavours argument. It may or may not work depending on how you write your code. If you rely on that feature your app may very well stop working properly (e.g. it may expose it to security issues). It's very much creating two flavors. Regarding the alpha release, I think there are two key issues here: 1. Does this alpha mean anything at all. Some, myself included, don't feel comfortable about the state of certain things in the current codebase (example given above). Are we all in sync that even if a certain feature makes it into the alpha, it doesn't mean that it won't be removed or be severely modified in an upcoming beta/GA? Is it clear it has no implications on when the final release would be? That is, at least, the way I perceive alpha releases. In which case it's not exactly clear to me what the benefits of releasing an Alpha in this day and age for PHP - where we have snapshots every few hours. We need to have a very clear understanding of what this does or doesn't mean, and make sure we communicate it properly to the users. To me this alpha would be a this is what we're mostly likely going to have thing. I wouldn't like to see new major features, engine rework being done; but I also think we shouldn't try to remove stuff from it unless really necessary. If that's the case, count me in those who oppose the release of the current codebase as an alpha. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Release Process
-Original Message- From: Matthew Weier O'Phinney [mailto:weierophin...@php.net] Sent: 23 November 2010 14:18 To: internals@lists.php.net Subject: Re: [PHP-DEV] [RFC] Release Process On 2010-11-23, Derick Rethans der...@php.net wrote: On Tue, 23 Nov 2010, Ferenc Kovacs wrote: All the rest you write in the RFC is basically already as we do it. yeah, maybe, but they aren't written down, accepted and well-known rules, so you can forgot/misunderstand/bend them. :/ And I don't think that is a bad thing. It's good to be able to be flexible. A good artist is capable of great flexibility within the constraints of their medium. In the case of software releases, you can still have greate flexibility even with an existing release process. In many ways, having the process defined helps bring about creative solutions -- if I want to get this in time for the release, what solution will work best? I used to love the ad hoc nature of we'll release when it's ready. However, having done quite a number of scheduled releases, I've found that: * Predictability motivates developers. Release is in 3 months? Okay, let's get rolling on this! * Knowing when the next release is coming also means that developers are more comfortable if they're unable to make the deadline. I can't do it by this release, but I should have no trouble making the next. * Less stressful for release managers. If the code isn't ready by the deadline, it's not merged to the branch, plain and simple. The status quo works great for those whom it serves. For everyone else, it stinks. There's no transparency, which leads to disenfranchisement. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc +1 PHP is big/grown-up/widely-used enough now that shipping is a feature It's gone beyond just being a beginners tool for knocking out basic web pages. Enterprise (who-ever that is :-) now uses PHP and as such will want PHP to have some degree of uniformity with release cycles and feature addition/removal so that they can easily factor it in to their own deployment/upgrade plans etc. While they dislike change (tongue in cheek), they dislike the unknown more. Transparency also helps people get on board from both a developer perspective and user one too. It gives little people the warm and fuzzy feeling because they can at least understand how everything works/decisions are made even if they aren't involved in them, and if they did want to get involved, they can see what they have to do. just my 2 cents. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Hold off 5.4
On Tue, 23 Nov 2010, Zeev Suraski wrote: To me this alpha would be a this is what we're mostly likely going to have thing. I wouldn't like to see new major features, engine rework being done; but I also think we shouldn't try to remove stuff from it unless really necessary. If that's the case, count me in those who oppose the release of the current codebase as an alpha. I find it interesting that apparently so many people don't want a new PHP version out, but forget to say what they think needs fixing. Instead of opposing, can we not do just some work? Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Release Process
On Tue, 23 Nov 2010, Ferenc Kovacs wrote: On Tue, Nov 23, 2010 at 2:59 PM, Derick Rethans der...@php.net wrote: On Tue, 23 Nov 2010, Ferenc Kovacs wrote: All the rest you write in the RFC is basically already as we do it. yeah, maybe, but they aren't written down, accepted and well-known rules, so you can forgot/misunderstand/bend them. :/ And I don't think that is a bad thing. It's good to be able to be flexible. Its good for you, but its bad for the people, who expect you to follow the rules, you know, the vendors, developers, etc. Well, vendors don't follow rules in the first place. They just add random patches anyway. Developers are pretty much aware what a bug fix, security bug fix and development tree means. With an annoucement (which should really be a regular thing, sortof) of a new minor release, isn't it clear? In case you say no, don't write an RFC that requires really strict following, but instead write guidelines that match current practise. Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Hold off 5.4
If it doesn't check for the hints, then your application will still work. I will say this once more: this is a *debugging* aid. If your app *relies* on it, then it means it will probably not use other means to ensure that the data is of the correct type, which may result in all sorts of issues. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Release Process
On Tue, Nov 23, 2010 at 3:58 PM, Derick Rethans der...@php.net wrote: On Tue, 23 Nov 2010, Ferenc Kovacs wrote: On Tue, Nov 23, 2010 at 2:59 PM, Derick Rethans der...@php.net wrote: On Tue, 23 Nov 2010, Ferenc Kovacs wrote: All the rest you write in the RFC is basically already as we do it. yeah, maybe, but they aren't written down, accepted and well-known rules, so you can forgot/misunderstand/bend them. :/ And I don't think that is a bad thing. It's good to be able to be flexible. Its good for you, but its bad for the people, who expect you to follow the rules, you know, the vendors, developers, etc. Well, vendors don't follow rules in the first place. you are sure that there aren't any vendor out there that don't following your rules, which you think it better if it isn't documented or followed? They just add random patches anyway. usually they more lazy, than the original developers, so I think they don't add random shit just for fun. Developers are pretty much aware what a bug fix, security bug fix and development tree means. as long as you and Zeev can't agree on what is the trunk (either be that a development/experience branch, or the next stable version), then I think they aren't aware. With an annoucement (which should really be a regular thing, sortof) of a new minor release, isn't it clear? sorry, I lost you here. what is clear? that you want to release the current trunk? thats crystal clear. What it's not clear to me, that who decided when that you will be the current RM, and that the current trunk is ready for an alpha release. what is an alpha release? when did we started releasing and announcing alphas, who decided that? can we add new features after the alpha? or can we remove something if the feedback is bad about some change? so this is what I'm talking about, lack of In case you say no, don't write an RFC that requires really strict following, but instead write guidelines that match current practise. from my POV, I don't mind, if you guys decide that the current process is the best, and create a wiki for that, but please decide on that, write it down, and at least try to stick with it, if it works. thats the point. Tyrael
Re: [PHP-DEV] Hold off 5.4
I too must second Mike's comments about pecl_http not being quite ready for bundling. The extension provides some useful functionality, no doubt (I use it ;-)). But I don't think there is a good case for bundling it. On Tue, Nov 23, 2010 at 7:40 AM, Michael Wallner m...@php.net wrote: On 11/23/2010 10:57 AM, Derick Rethans wrote: On Mon, 22 Nov 2010, Felipe Pena wrote: - pecl/http was planned to be bundled. What's the status? I'm all for it; but again, it's just copying it over to trunk before we branch. ... - copy over APC/pecl_http - branch on thursday - alpha next week - build a list of things that needs doing in 5.4 to get it ready (with possible options to get rid of apc/pecl_http if they are not up to date enough) Huh? I'm quite surprised to read that pecl/http is planned to be bundled with trunk, while--sure--my grand master plan included this option, there's only pecl/http/branches/DEV_2 which is compatible with trunk and I doubt you all are talking about that version? It still needs some serious amount of work, development has stalled again due to my job's demands. Cheers, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Release Process
I think support 5 or even 3 parallel versions will be highly impractical and extra-ordinarily challenging. I think we need a plan that limits us to 2 versions and perhaps a 3rd one for critical security fixes only. 2010/11/23 Johannes Schlüter johan...@schlueters.de: Hi, On Mon, 2010-11-22 at 23:21 -0200, Felipe Pena wrote: With the recent chaos in the way we begin and ended releases, we would like to propose a clean way to deal with releases and related decisions: [1] Thanks for preparing this. I have one change proposal: With the proposed model it might, as you have illustrated, happen that there are 5 versions being maintained. As I mentioned multiple times on this list, on irc and other places I like a Ubuntu-like model with two kinds of release which I, for the purpose of this discussion, call early access (EA) and long term supported (LTS) version. At any given time only one EA may exist. When a new LTS version is being released the previous LTS version enters security-only mode to give users a transition period. Between every LTS version there are two EA versions. 2011 2012 2013 2014 2015 2016 2017 | | | | | | | | | | | | | LTS1 +---D | | | | EA1 | | D | | | | | | | | EA2 | | | | D | | | | | | LTS2 | | | | | | ---D EA3 | | | | | | | | D EA4 | | | | | | | | | | D The benefit is that developers and users who require a specific feature get it early while distributors/hosters/software vendors/... have a safe bet. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] --enable-zend-multibyte
On 11/23/2010 01:34 AM, Dmitry Stogov wrote: hi, I've prepared the patch which completely removes compile-time --enable-zend-multibyte configuration directive. The configuration can be changed at run-tume using zend.multibyte=0/1. The patch also fixes Unicode detection for phar archives. I would like to commit it on Thursday. Thanks. Dmitry. Hi Dmitry, The UPGRADING file needs to updated. I'd argue that the zend.multibyte should be included in php.ini-* (along with detect_unicode, zend.enable_gc etc) Chris PS a brief RFC capturing the essentials of the change would help the Doc team. -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Release Process
2010/11/23 Ilia Alshanetsky i...@prohost.org I think support 5 or even 3 parallel versions will be highly impractical and extra-ordinarily challenging. I think we need a plan that limits us to 2 versions and perhaps a 3rd one for critical security fixes only. 2010/11/23 Johannes Schlüter johan...@schlueters.de: Hi, On Mon, 2010-11-22 at 23:21 -0200, Felipe Pena wrote: With the recent chaos in the way we begin and ended releases, we would like to propose a clean way to deal with releases and related decisions: [1] Thanks for preparing this. I have one change proposal: With the proposed model it might, as you have illustrated, happen that there are 5 versions being maintained. As I mentioned multiple times on this list, on irc and other places I like a Ubuntu-like model with two kinds of release which I, for the purpose of this discussion, call early access (EA) and long term supported (LTS) version. At any given time only one EA may exist. When a new LTS version is being released the previous LTS version enters security-only mode to give users a transition period. Between every LTS version there are two EA versions. 20112012 2013 201420152016 2017 | | | | | | | | | | | | | LTS1+---D | | | | EA1 | | D | | | | | | | | EA2 | | | | D | | | | | | LTS2| | | | | | ---D EA3 | | | | | | | | D EA4 | | | | | | | | | | D The benefit is that developers and users who require a specific feature get it early while distributors/hosters/software vendors/... have a safe bet. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php You can't expect the users to switch to the new major version as soon as it comes out. They have to either migrate their codebase, and sadly they will wait(at least me and my collegues/friends do this) one or two micro/build version bump, usually the new major/major.minor version is stable enough. So if we want to support equally 2 major version concurrently, I can't see how can we make it through supporting 4 branches (oldmajor.last, oldmajor.current, newmajor.last, newmajor.current) or we can make unequal or favored branches: - either an early adopter vs lts sytem like ubuntu does, but they have 4 supported version at a time also https://wiki.ubuntu.com/LTS but I don't know how to mix LTS and php, because they release shared nothing versions, while the php versions does share a common codebase through their major version, so we can't plan beforehand that what version will be the nextlts before getting there like the ubuntu guys can. :/ - or stopping the development on the oldmajor version (I mean no new minor version for the oldmajor, only micro/build bugfix releases) with that modification, the multiple major version would be like this: http://wiki.php.net/rfc/releaseprocessalternatives what do you think? Tyrael
Re: [PHP-DEV] Hold off 5.4
Hi! During our namespace discussion, this is exactly what I warned about. In order to make use of namespaces, you need to have atleast two elements in your class names otherwise we can still never introduce a new class. But that was not listened too. I'm not sure I understand this point, could you explain? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] --enable-zend-multibyte
Hi Chris, I've added a note into UPGRADING, but I didn't change php.ini-* Thanks. Dmitry. Christopher Jones wrote: On 11/23/2010 01:34 AM, Dmitry Stogov wrote: hi, I've prepared the patch which completely removes compile-time --enable-zend-multibyte configuration directive. The configuration can be changed at run-tume using zend.multibyte=0/1. The patch also fixes Unicode detection for phar archives. I would like to commit it on Thursday. Thanks. Dmitry. Hi Dmitry, The UPGRADING file needs to updated. I'd argue that the zend.multibyte should be included in php.ini-* (along with detect_unicode, zend.enable_gc etc) Chris PS a brief RFC capturing the essentials of the change would help the Doc team. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
