Hello,
I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved
trunk to the branch FIRST_UNICODE_IMPLEMENTATION.
The next things to do is to re-create trunk from PHP 5.3; I've hold off
that for now, but I'd like to do the following soon:
- Declare 5.2 security fixes only (Something for Ilia to declare).
- Declare 5.3 bug fixes only (and ini-mini features if so desired)
(Something for Johannes to declare).
Once that's done, I'd like to:
- Recreate trunk from the 5.3 branch.
Before we add features, they need to be discussed whether we want to
have them. As version name for it I would like to use "trunk-dev" (and
not 5.4-dev or 6.0-dev) as we're not quite sure where this is moving.
Right now, there are the following features that I can see we should
think about:
- the new output buffering mechanism (I can not really see why we would
not want this) - Scott's big number improvements. Scott, can you explain (in an RFC)
what exactly this does and how it works? - Ilia's scalar type hint patch. There are RFCs:
http://wiki.php.net/rfc/typechecking - traits, there are also RFCs:
http://wiki.php.net/rfc/horizontalreuse
http://wiki.php.net/rfc/nonbreakabletraits
with kind regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
- Declare 5.2 security fixes only (Something for Ilia to declare).
- Declare 5.3 bug fixes only (and ini-mini features if so desired)
(Something for Johannes to declare).Once that's done, I'd like to:
Recreate trunk from the 5.3 branch.
the new output buffering mechanism (I can not really see why we would
not want this)
is there something about that in the wiki? I think a few lines in the wiki
about this would be good.
- Scott's big number improvements. Scott, can you explain (in an RFC)
what exactly this does and how it works?- Ilia's scalar type hint patch. There are RFCs:
http://wiki.php.net/rfc/typechecking- traits, there are also RFCs:
http://wiki.php.net/rfc/horizontalreuse
http://wiki.php.net/rfc/nonbreakabletraits
thank you.
I agree that we should discuss new additions with proper rfcs before we commit
them. in addition to that peopled interested in unicode should get together and
discuss how to readd unicode support and in which way to do this.
- Declare 5.2 security fixes only (Something for Ilia to declare).
- Declare 5.3 bug fixes only (and ini-mini features if so desired)
(Something for Johannes to declare).Once that's done, I'd like to:
Recreate trunk from the 5.3 branch.
the new output buffering mechanism (I can not really see why we would
not want this)
is there something about that in the wiki? I think a few lines in the wiki
about this would be good.
I doubt it. Its a rewrite which had to be done to simplify things and
fixes several bugs.
-Hannes
Right now, there are the following features that I can see we should
think about:
- the new output buffering mechanism (I can not really see why we would
not want this)- Scott's big number improvements. Scott, can you explain (in an RFC)
what exactly this does and how it works?- Ilia's scalar type hint patch. There are RFCs:
http://wiki.php.net/rfc/typechecking- traits, there are also RFCs:
http://wiki.php.net/rfc/horizontalreuse
http://wiki.php.net/rfc/nonbreakabletraits
- merge php-fpm branch?
--
Alexey Zakhlestin
http://www.milkfarmsoft.com/
Right now, there are the following features that I can see we should
think about:
- the new output buffering mechanism (I can not really see why we would
not want this)- Scott's big number improvements. Scott, can you explain (in an RFC)
what exactly this does and how it works?- Ilia's scalar type hint patch. There are RFCs:
http://wiki.php.net/rfc/typechecking- traits, there are also RFCs:
http://wiki.php.net/rfc/horizontalreuse
http://wiki.php.net/rfc/nonbreakabletraits
- merge php-fpm branch?
Can't see why not. Is there an RFC for this?
regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
- merge php-fpm branch?
Can't see why not. Is there an RFC for this?
No, there are no RFCs on that.
Just copy sapi/fpm to 5_4 and you've merged it.
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
- merge php-fpm branch?
Can't see why not. Is there an RFC for this?
No, there are no RFCs on that.
Just copy sapi/fpm to 5_4 and you've merged it.
There is no 5.4 either, trunk is the way for now.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
-----Original Message-----
From: Antony Dovgal [mailto:tony@daylessday.org]
Sent: Wednesday, March 17, 2010 2:25 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] PHP 5.4 branch and trunk
- merge php-fpm branch?
Can't see why not. Is there an RFC for this?
No, there are no RFCs on that.
Just copy sapi/fpm to 5_4 and you've merged it.
I think it'd actually be a good idea to have RFCs for major pieces of new functionality even if they are retroactively written for cases such as sapi/fpm and new output buffering. Quite a bit of time has passed and it's good documentation for the new releases + gives people an opportunity to review as we work towards the next big release. It may just mean refactoring a past email that describes this in detail so doesn't have to be huge effort but would be good to be more organized with the new release.
Andi
- merge php-fpm branch?
Can't see why not. Is there an RFC for this?
No, there are no RFCs on that.
Just copy sapi/fpm to 5_4 and you've merged it.
There is no 5_4, but still, I think there should be at least some docs
on what it does, and which features and problems it addresses. Saves the
doc team some work as well, and we know what we're getting ourselves
into.
with kind regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
- merge php-fpm branch?
If we get a trunk which will be released in a foreseeable timeframe we
don't need to merge this to 5.3 anymore, which had been an old plan.
Tony, do you agree?
johannes
- merge php-fpm branch?
If we get a trunk which will be released in a foreseeable timeframe we
don't need to merge this to 5.3 anymore, which had been an old plan.
Tony, do you agree?
Makes sense to me.
--
Wbr,
Antony Dovgal
http://pinba.org - realtime statistics for PHP
Am 16.03.2010 16:58, schrieb Derick Rethans:
I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved
trunk to the branch FIRST_UNICODE_IMPLEMENTATION.
Why do we need THE_5_4_THAT_ISNT_5_4 and trunk? trunk should be where
the development happens. When the time comes for a release, PHP_X_Y
should be branched off of trunk.
--
Sebastian Bergmann Co-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
On Tue, Mar 16, 2010 at 5:43 PM, Sebastian Bergmann
sb@sebastian-bergmann.de wrote:
Am 16.03.2010 16:58, schrieb Derick Rethans:
I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved
trunk to the branch FIRST_UNICODE_IMPLEMENTATION.Why do we need THE_5_4_THAT_ISNT_5_4
Right, this branch must be deleted, useless. The OB patch can be
merged again in trunk when trunk has been rebranched.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
On Tue, Mar 16, 2010 at 5:43 PM, Sebastian Bergmann
sb@sebastian-bergmann.de wrote:Am 16.03.2010 16:58, schrieb Derick Rethans:
I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved
trunk to the branch FIRST_UNICODE_IMPLEMENTATION.Why do we need THE_5_4_THAT_ISNT_5_4
Right, this branch must be deleted, useless. The OB patch can be
merged again in trunk when trunk has been rebranched.
Why exactly do we need to duplicate the work?
IMO that branch should be renamed to trunk/ and those 2 or 3 patches
to 5.3 to merged into it.
-Hannes
Before we add features, they need to be discussed whether we want to
have them.
Does that mean you want to take up a
- strict RFC-and-after-3months-discussion-before-commit policy
(i.e. killing the scratching-an-itch spirit of PHP) - "I'm going to commit this patch tomorrow" mail to internals@
(i.e. killing "I need this functionality, maybe others do to" spirit of PHP)
or what exactly do you mean by that?
I would much rather have a development branch which ""everything
goes"" (like it used to) and then make it up to the release manager to
merge the features he wants in "his branch" (DVCS style)
- Ilia's scalar type hint patch.
And which of Ilias patches are you referring to? The original one
(which is identical to the patch I sent in November 2006) or the
"fucking eyh, I need to please everyone so this can be in 5.3 - but
still got rejected" patch?
You didn't even list the mbstring patch.. that was discussed and as
far as I remember everyone thought it was great idea, just not in a
stable branch.
-Hannes
Hi!
Does that mean you want to take up a
- strict RFC-and-after-3months-discussion-before-commit policy
(i.e. killing the scratching-an-itch spirit of PHP)- "I'm going to commit this patch tomorrow" mail to internals@
(i.e. killing "I need this functionality, maybe others do to" spirit of PHP)
Probably something like "I have this patch and I wrote this RFC, please
discuss", then wait reasonable* time for discussion and reasonable*
consensus before commit, and for reasonably* small patches "I'm going to
commit it in 2 days unless somebody objects" would work
(*) I know definitions of "reasonable" differ but I have faith we find a
common ground.
And which of Ilias patches are you referring to? The original one
(which is identical to the patch I sent in November 2006) or the
"fucking eyh, I need to please everyone so this can be in 5.3 - but
still got rejected" patch?
That's exactly why having RFC is good - one link solves all the
questions about "which one is it' :)
--
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Does that mean you want to take up a
- strict RFC-and-after-3months-discussion-before-commit policy
(i.e. killing the scratching-an-itch spirit of PHP)- "I'm going to commit this patch tomorrow" mail to internals@
(i.e. killing "I need this functionality, maybe others do to" spirit of
PHP)Probably something like "I have this patch and I wrote this RFC, please
discuss", then wait reasonable* time for discussion and reasonable* consensus
before commit, and for reasonably* small patches "I'm going to commit it in 2
days unless somebody objects" would work(*) I know definitions of "reasonable" differ but I have faith we find a
common ground.
Yup, that's what I was thinking about.
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Before we add features, they need to be discussed whether we want to
have them.Does that mean you want to take up a
- strict RFC-and-after-3months-discussion-before-commit policy
(i.e. killing the scratching-an-itch spirit of PHP)- "I'm going to commit this patch tomorrow" mail to internals@
(i.e. killing "I need this functionality, maybe others do to" spirit of PHP)
Its all a question about the scope of the change obviously. There is some tipping point where it makes sense for an RFC. Remember an RFC not only serves decision making, but also provides some level of documentation (on which the final documentation can be build) for past generations (this is why I for example wrote the ifsetor RFC after we decided that we cannot currently implement it).
So like Stas said .. common sense still rules.
I would much rather have a development branch which ""everything
goes"" (like it used to) and then make it up to the release manager to
merge the features he wants in "his branch" (DVCS style)
I dont think we ever had an "everything goes" HEAD .. lets say in the past we had a small very active core dev team with really short turn around times for decisions because everybody was answering on IRC or mailinglists within minutes. As a result decisions (not always for the better) were made in a much shorter timeframe than the current availability of core developers affords us.
- Ilia's scalar type hint patch.
And which of Ilias patches are you referring to? The original one
(which is identical to the patch I sent in November 2006) or the
"fucking eyh, I need to please everyone so this can be in 5.3 - but
still got rejected" patch?
I think he clearly pointed to the wiki page which lists 3 proposals. He is just suggesting we should finalize which one we want and get it in.
You didn't even list the mbstring patch.. that was discussed and as
far as I remember everyone thought it was great idea, just not in a
stable branch.
Is this tone really necessary? One you are argueing for more flexibility and then you are shooting the messenger because in a long list he forgot one thing (there are probably a few others .. we might want to go through the todo wiki pages for more)?
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
You didn't even list the mbstring patch.. that was discussed and as
far as I remember everyone thought it was great idea, just not in a
stable branch.Is this tone really necessary? One you are argueing for more flexibility and then you are shooting the messenger because in a long list he forgot one thing (there are probably a few others .. we might want to go through the todo wiki pages for more)?
"tones" are misleading :]
One of the things we already discussed before this thread was to
attempt alternative ways to approach "the unicode problem".
That mbstring patch is one of those ways. Its nonintrusive (well, to
other parts of the language) and should be relatively backwards
compatible and improves the extension quite a lot.
-Hannes
Before we add features, they need to be discussed whether we want to
have them. As version name for it I would like to use "trunk-dev" (and
not 5.4-dev or 6.0-dev) as we're not quite sure where this is moving.
Right now, there are the following features that I can see we should
think about:
Since we do not know the name of the next version yet, maybe its best to base the name on what version it will have as a predecessor and add support for this in version_compare()? Something like "5.3post". Ok this isnt a good suggestion, but I hope you get what I am suggesting.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
Before we add features, they need to be discussed whether we want to
have them. As version name for it I would like to use "trunk-dev" (and
not 5.4-dev or 6.0-dev) as we're not quite sure where this is moving.
Right now, there are the following features that I can see we should
think about:Since we do not know the name of the next version yet, maybe its best to
base the name on what version it will have as a predecessor and add
support for this inversion_compare()? Something like "5.3post". Ok this
isnt a good suggestion, but I hope you get what I am suggesting.
We need a version number which can be represented as a numeric value
like
#define PHP_VERSION_ID 50303
to help extension authors; as said on IRC 5.4 is the only sane choice
there. We can still increase the number if needed.
How to document this is a good question...
johannes
Zitat von Johannes Schlüter johannes@php.net:
Before we add features, they need to be discussed whether we want to
have them. As version name for it I would like to use "trunk-dev" (and
not 5.4-dev or 6.0-dev) as we're not quite sure where this is moving.
Right now, there are the following features that I can see we should
think about:Since we do not know the name of the next version yet, maybe its best to
base the name on what version it will have as a predecessor and add
support for this inversion_compare()? Something like "5.3post". Ok this
isnt a good suggestion, but I hope you get what I am suggesting.We need a version number which can be represented as a numeric value
like#define
PHP_VERSION_ID50303to help extension authors; as said on IRC 5.4 is the only sane choice
there. We can still increase the number if needed.How to document this is a good question...
How about 5.3.99? A lot of projects use this for pre-releases, but it
still might make sense.
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
How about 5.3.99? A lot of projects use this for pre-releases, but it still
might make sense.
I'm wary of sticking with anything starting with 5.3 if we're going to
break binary compatibility on the new trunk (which we presumably are)
— it undermines the usual binary compatibility guarantees on "stable"
branches, even given that the new trunk is a development branch. As
Johannes said:
We can still increase the number if needed.
I completely agree. IMO, there's nothing wrong with calling it 5.4 now
and renumbering it to 6.0/7.0/whatever (in the same manner as what
Postgres are currently doing with 8.5 becoming 9.0) later if it makes
sense to.
Adam
I've just renamed the 5.4 branch to THE_5_4_THAT_ISNT_5_4 and moved
Eventually it should be deleted, if it helps at all in merging the OB change then it should be kept until that happens, otherwise it can be deleted now imho. The new 5.3 based trunk will emerge soon I am sure, but until then lets not bother with having to merge those changes.
trunk to the branch FIRST_UNICODE_IMPLEMENTATION.
+1
The next things to do is to re-create trunk from PHP 5.3; I've hold off
that for now, but I'd like to do the following soon:
- Declare 5.2 security fixes only (Something for Ilia to declare).
- Declare 5.3 bug fixes only (and ini-mini features if so desired)
(Something for Johannes to declare).
+1
- the new output buffering mechanism (I can not really see why we would
not want this)
+1
- traits, there are also RFCs:
http://wiki.php.net/rfc/horizontalreuse
http://wiki.php.net/rfc/nonbreakabletraits
+1
other stuff:
http://wiki.php.net/todo/php60
http://wiki.php.net/todo/backlog
That being said I think until we know if the next version will be a new major version, we should hold off on BC breaking cleanup stuff likes dropping register globals and friends. But we still might bundle APC with the next release for example, even if its not 6.0 ..
--
As for unicode, I would like the next release to be planned independently of finding a solution for unicode, but with the clear option that it will be included if we find a good solution in time (like I said I think it would be good to shoot for a final release summer 2011, so beta phase in early 2011). I propose that sort of a unicode working group forms but much less formal than what I make it sound like. I think the discussions can remain on internals@ and hopefully alternative approaches will be documented as RFCs. But what I mean with working group is a list of a handful of names who feel responsible to keep this topic moving until a solution is found and who people know they can contact if they want to chat or whatever.
Again if these guys find a workable solution that can be implemented this year and I am all for putting it into the next release. If not so be it, because I think the lesson learned in all of the PHP6/PHP5.3 release nightmare is that we should have regular releases. So I say we shoot for the release following the next one to come out in the summer of 2012.
regards,
Lukas Kahwe Smith
mls@pooteeweet.org
other stuff:
http://wiki.php.net/todo/php60
http://wiki.php.net/todo/backlog
yeah, I know there is other stuff, I was just listing a few examples of
things I remembered. Both lists require some scrutiny as I can see from
a quick glance.
As for unicode, I would like the next release to be planned
independently of finding a solution for unicode, but with the clear
option that it will be included if we find a good solution in time
(like I said I think it would be good to shoot for a final release
summer 2011, so beta phase in early 2011).
I do agree that we need to do major releases more often, but just
setting a time already feels wrong. It's still open source, so it's
ready when it is ready. That of course should not mean that we should
keep on adding features endlessly.
I propose that sort of a
unicode working group forms but much less formal than what I make it
sound like. I think the discussions can remain on internals@ and
hopefully alternative approaches will be documented as RFCs. But what
I mean with working group is a list of a handful of names who feel
responsible to keep this topic moving until a solution is found and
who people know they can contact if they want to chat or whatever.
So how would that "group" differ from just internals@ ?
Again if these guys find a workable solution that can be implemented
this year and I am all for putting it into the next release.
It might also be possible to introduce Unicode step by step. Not
everything does necessarily have to be done in one release.
regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
As for unicode, I would like the next release to be planned
independently of finding a solution for unicode, but with the clear
option that it will be included if we find a good solution in time
(like I said I think it would be good to shoot for a final release
summer 2011, so beta phase in early 2011).I do agree that we need to do major releases more often, but just
setting a time already feels wrong. It's still open source, so it's
ready when it is ready. That of course should not mean that we should
keep on adding features endlessly.
Maybe because it is the only way to garantee a reasonable time frame
for releases, avoid commits rushes right before the freeze, etc. As
I've been said before already, I'm all for a fixed release cycle, it
is then much easier to define clear priorities and roadmaps.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
I do agree that we need to do major releases more often, but just
setting a time already feels wrong. It's still open source, so it's
ready when it is ready. That of course should not mean that we should
keep on adding features endlessly.for releases, avoid commits rushes right before the freeze, etc. As
I've been said before already, I'm all for a fixed release cycle, it
is then much easier to define clear priorities and roadmaps.
+1. i think having a fixed release cycle has nothing to do with
being opensource or not but with being more predictable for people
depending on release dates.
On Thu, Mar 18, 2010 at 6:16 PM, Derick Rethans derick@php.net
wrote:I do agree that we need to do major releases more often, but just
setting a time already feels wrong. It's still open source, so it's
ready when it is ready. That of course should not mean that we
should
keep on adding features endlessly.for releases, avoid commits rushes right before the freeze, etc. As
I've been said before already, I'm all for a fixed release cycle, it
is then much easier to define clear priorities and roadmaps.+1. i think having a fixed release cycle has nothing to do with
being opensource or not but with being more predictable for people
depending on release dates.
right. and again i think i was quite explict in my original mail that
common sense still applies. if we have a buggy release we will
obviously not release it just because. as for having enough to
actually warrant a release i do not ever remember a time where there
werent atleast a handful feasible proposals in varying size on the
table.
regard
Lukas
On Thu, Mar 18, 2010 at 4:50 PM, Lukas Kahwe Smith mls@pooteeweet.orgwrote:
I do agree that we need to do major releases more often, but just
setting a time already feels wrong. It's still open source, so it's
ready when it is ready. That of course should not mean that we should
keep on adding features endlessly.for releases, avoid commits rushes right before the freeze, etc. As
I've been said before already, I'm all for a fixed release cycle, it
is then much easier to define clear priorities and roadmaps.+1. i think having a fixed release cycle has nothing to do with
being opensource or not but with being more predictable for people
depending on release dates.right. and again i think i was quite explict in my original mail that
common sense still applies. if we have a buggy release we will obviously not
release it just because. as for having enough to actually warrant a release
i do not ever remember a time where there werent atleast a handful feasible
proposals in varying size on the table.regard
Lukas--
+1 For shorter release cycles. Shorter release cycles could also allow us to
move major releases immediately to bug and security fixes only. I've never
been a fan of seeing additional features added in minor releases. It's
confusing enough to try and keep track of features from one major release to
the next, but then we add in features on minors as well. "That feature was
added in 5.3.1". Obviously this was not a good option when major releases
were at 12 months or more apart. If we can shorten the cycle, I think it
might be a good idea to visit how quickly each release is frozen to bug and
security fixes only. This may just be a developmental pet-peave of mine, I'm
sure I'll hear about it soon if the idea is unfavorable.
As an additional note to this, performance patches which don't add
additional features but only increase speed would still be fair game.
P.S. 2: Reduced release cycle times might reduce the burdens on RMs as well
by allowing them to commit to shorter time periods of release management
responsibility. Not that I hear any of them complaining, just thinking this
might be another good reason to give it a try.
Eric Lee Stewart
On Thursday 18 March 2010 10:05:39 pm Eric Stewart wrote:
+1 For shorter release cycles. Shorter release cycles could also allow us
to move major releases immediately to bug and security fixes only. I've
never been a fan of seeing additional features added in minor releases.
It's confusing enough to try and keep track of features from one major
release to the next, but then we add in features on minors as well. "That
feature was added in 5.3.1". Obviously this was not a good option when
major releases were at 12 months or more apart. If we can shorten the
cycle, I think it might be a good idea to visit how quickly each release
is frozen to bug and security fixes only. This may just be a developmental
pet-peave of mine, I'm sure I'll hear about it soon if the idea is
unfavorable.As an additional note to this, performance patches which don't add
additional features but only increase speed would still be fair game.P.S. 2: Reduced release cycle times might reduce the burdens on RMs as well
by allowing them to commit to shorter time periods of release management
responsibility. Not that I hear any of them complaining, just thinking this
might be another good reason to give it a try.Eric Lee Stewart
If I could step in for a moment, while there's certainly advantages to shorter
release cycles that others have mentioned there's another factor that has to
be considered: Backward compatibility would have to be much more tightly
monitored.
Out in the shared hosting world, we're at the mercy of web hosts and Linux
distributions. They don't like to upgrade stuff if they don't have to, and
often times not even then. It wasn't that long ago that we needed an
industry-wide boycott, essentially, to force PHP 5 at all. Most hosts aren't
on 5.3 yet. That means any mass-market PHP projects (Wordpress, Drupal,
Joomla, CakePHP, Symfony, CodeIgnighter, etc.) are still working with 5.2 at
best, and it may be some time before the "I don't have root on my server and
don't know how to compile stuff myself" crowd (read: the vast majority of the
market) is able to leverage 5.3.
When significant releases are 2-3 years apart, web hosts can expect to have to
put in actual work every couple of years and mass-market developers can expect
to have to beat their hosts over the head with a stick every few years. If
significant releases are going to be every year, then it has to still be easy
and safe for hosts to upgrade. Preferably it has to also make servers faster
because then they have an incentive to upgrade themselves. If hosts don't
upgrade, it doesn't matter what amazing new features PHP has. Most people
can't use 'em.
I'm not against a more planned, frequent release cycle but I want to make sure
that the upgrade treadmill is kept walkable or else it won't matter that PHP
has new features.
--Larry Garfield
On Thursday 18 March 2010 10:05:39 pm Eric Stewart wrote:
+1 For shorter release cycles. Shorter release cycles could also allow us
to move major releases immediately to bug and security fixes only. I've
never been a fan of seeing additional features added in minor releases.
It's confusing enough to try and keep track of features from one major
release to the next, but then we add in features on minors as well. "That
feature was added in 5.3.1". Obviously this was not a good option when
major releases were at 12 months or more apart. If we can shorten the
cycle, I think it might be a good idea to visit how quickly each release
is frozen to bug and security fixes only. This may just be a developmental
pet-peave of mine, I'm sure I'll hear about it soon if the idea is
unfavorable.As an additional note to this, performance patches which don't add
additional features but only increase speed would still be fair game.P.S. 2: Reduced release cycle times might reduce the burdens on RMs as well
by allowing them to commit to shorter time periods of release management
responsibility. Not that I hear any of them complaining, just thinking this
might be another good reason to give it a try.Eric Lee Stewart
If I could step in for a moment, while there's certainly advantages to shorter
release cycles that others have mentioned there's another factor that has to
be considered: Backward compatibility would have to be much more tightly
monitored.Out in the shared hosting world, we're at the mercy of web hosts and Linux
distributions. They don't like to upgrade stuff if they don't have to, and
often times not even then. It wasn't that long ago that we needed an
industry-wide boycott, essentially, to force PHP 5 at all. Most hosts aren't
on 5.3 yet. That means any mass-market PHP projects (Wordpress, Drupal,
Joomla, CakePHP, Symfony, CodeIgnighter, etc.) are still working with 5.2 at
best, and it may be some time before the "I don't have root on my server and
don't know how to compile stuff myself" crowd (read: the vast majority of the
market) is able to leverage 5.3.When significant releases are 2-3 years apart, web hosts can expect to have to
put in actual work every couple of years and mass-market developers can expect
to have to beat their hosts over the head with a stick every few years. If
significant releases are going to be every year, then it has to still be easy
and safe for hosts to upgrade. Preferably it has to also make servers faster
because then they have an incentive to upgrade themselves. If hosts don't
upgrade, it doesn't matter what amazing new features PHP has. Most people
can't use 'em.I'm not against a more planned, frequent release cycle but I want to make sure
that the upgrade treadmill is kept walkable or else it won't matter that PHP
has new features.
I think that the hosting companies will adapt as slow as they can, so
if we give more frequent releases, then they will (have to) upgrade
more often.
Additionaly if we release more frequently but with fewer changes, then
the developers can adapt more easily, because they have to watch out
for one or two change at a time, not a whole lot of changes.
Tyrael
--Larry Garfield
On Fri, Mar 19, 2010 at 4:20 AM, Larry Garfield larry@garfieldtech.com
wrote:On Thursday 18 March 2010 10:05:39 pm Eric Stewart wrote:
+1 For shorter release cycles. Shorter release cycles could also allow
us
to move major releases immediately to bug and security fixes only. I've
never been a fan of seeing additional features added in minor releases.
It's confusing enough to try and keep track of features from one major
release to the next, but then we add in features on minors as well.
"That
feature was added in 5.3.1". Obviously this was not a good option when
major releases were at 12 months or more apart. If we can shorten the
cycle, I think it might be a good idea to visit how quickly each
release
is frozen to bug and security fixes only. This may just be a
developmental
pet-peave of mine, I'm sure I'll hear about it soon if the idea is
unfavorable.As an additional note to this, performance patches which don't add
additional features but only increase speed would still be fair game.P.S. 2: Reduced release cycle times might reduce the burdens on RMs as
well
by allowing them to commit to shorter time periods of release management
responsibility. Not that I hear any of them complaining, just thinking
this
might be another good reason to give it a try.Eric Lee Stewart
If I could step in for a moment, while there's certainly advantages to
shorter
release cycles that others have mentioned there's another factor that has
to
be considered: Backward compatibility would have to be much more tightly
monitored.Out in the shared hosting world, we're at the mercy of web hosts and
Linux
distributions. They don't like to upgrade stuff if they don't have to,
and
often times not even then. It wasn't that long ago that we needed an
industry-wide boycott, essentially, to force PHP 5 at all. Most hosts
aren't
on 5.3 yet. That means any mass-market PHP projects (Wordpress, Drupal,
Joomla, CakePHP, Symfony, CodeIgnighter, etc.) are still working with 5.2
at
best, and it may be some time before the "I don't have root on my server
and
don't know how to compile stuff myself" crowd (read: the vast majority of
the
market) is able to leverage 5.3.When significant releases are 2-3 years apart, web hosts can expect to
have to
put in actual work every couple of years and mass-market developers can
expect
to have to beat their hosts over the head with a stick every few years.
If
significant releases are going to be every year, then it has to still be
easy
and safe for hosts to upgrade. Preferably it has to also make servers
faster
because then they have an incentive to upgrade themselves. If hosts
don't
upgrade, it doesn't matter what amazing new features PHP has. Most
people
can't use 'em.I'm not against a more planned, frequent release cycle but I want to make
sure
that the upgrade treadmill is kept walkable or else it won't matter that
PHP
has new features.I think that the hosting companies will adapt as slow as they can, so
if we give more frequent releases, then they will (have to) upgrade
more often.
Additionaly if we release more frequently but with fewer changes, then
the developers can adapt more easily, because they have to watch out
for one or two change at a time, not a whole lot of changes.
Being a guy who both runs a small hosting shop and spends lots of time doing
development. I would greatly appreciate more frequent, but smaller
releases. I just finally got 5.3 rolled out this week, and have been
wanting it for months for the performance improvements in realpath, but have
been hindered by the large list of things it would throw warnings about.
The other side of hosting is that most of your clients don't keep on top of
versions of their installed software. Even app developers don't want to go
make changes to a 5 year old app just because PHP has decided that something
is no longer a good practice. My guess is that I'm in the minority of hosts
that want to upgrade PHP for new features. Part of that is probably driven
by being a app developer for most of my job.
--
-Nathan Gordon
If the database server goes down and there is no code to hear it, does it
really go down?
<esc>:wq<CR
On Fri, Mar 19, 2010 at 4:20 AM, Larry Garfield larry@garfieldtech.com
wrote:On Thursday 18 March 2010 10:05:39 pm Eric Stewart wrote:
+1 For shorter release cycles. Shorter release cycles could also allow
us
to move major releases immediately to bug and security fixes only.
I've
never been a fan of seeing additional features added in minor
releases.
It's confusing enough to try and keep track of features from one
major
release to the next, but then we add in features on minors as well.
"That
feature was added in 5.3.1". Obviously this was not a good option
when
major releases were at 12 months or more apart. If we can shorten the
cycle, I think it might be a good idea to visit how quickly each
release
is frozen to bug and security fixes only. This may just be a
developmental
pet-peave of mine, I'm sure I'll hear about it soon if the idea is
unfavorable.As an additional note to this, performance patches which don't add
additional features but only increase speed would still be fair game.P.S. 2: Reduced release cycle times might reduce the burdens on RMs as
well
by allowing them to commit to shorter time periods of release
management
responsibility. Not that I hear any of them complaining, just thinking
this
might be another good reason to give it a try.Eric Lee Stewart
If I could step in for a moment, while there's certainly advantages to
shorter
release cycles that others have mentioned there's another factor that
has
to
be considered: Backward compatibility would have to be much more
tightly
monitored.Out in the shared hosting world, we're at the mercy of web hosts and
Linux
distributions. They don't like to upgrade stuff if they don't have to,
and
often times not even then. It wasn't that long ago that we needed an
industry-wide boycott, essentially, to force PHP 5 at all. Most hosts
aren't
on 5.3 yet. That means any mass-market PHP projects (Wordpress,
Drupal,
Joomla, CakePHP, Symfony, CodeIgnighter, etc.) are still working with
5.2
at
best, and it may be some time before the "I don't have root on my
server
and
don't know how to compile stuff myself" crowd (read: the vast majority
of
the
market) is able to leverage 5.3.When significant releases are 2-3 years apart, web hosts can expect to
have to
put in actual work every couple of years and mass-market developers can
expect
to have to beat their hosts over the head with a stick every few years.
If
significant releases are going to be every year, then it has to still
be
easy
and safe for hosts to upgrade. Preferably it has to also make servers
faster
because then they have an incentive to upgrade themselves. If hosts
don't
upgrade, it doesn't matter what amazing new features PHP has. Most
people
can't use 'em.I'm not against a more planned, frequent release cycle but I want to
make
sure
that the upgrade treadmill is kept walkable or else it won't matter
that
PHP
has new features.I think that the hosting companies will adapt as slow as they can, so
if we give more frequent releases, then they will (have to) upgrade
more often.
Additionaly if we release more frequently but with fewer changes, then
the developers can adapt more easily, because they have to watch out
for one or two change at a time, not a whole lot of changes.Being a guy who both runs a small hosting shop and spends lots of time
doing
development. I would greatly appreciate more frequent, but smaller
releases. I just finally got 5.3 rolled out this week, and have been
wanting it for months for the performance improvements in realpath, but
have
been hindered by the large list of things it would throw warnings about.
The other side of hosting is that most of your clients don't keep on top of
versions of their installed software. Even app developers don't want to go
make changes to a 5 year old app just because PHP has decided that
something
is no longer a good practice. My guess is that I'm in the minority of
hosts
that want to upgrade PHP for new features. Part of that is probably driven
by being a app developer for most of my job.--
-Nathan GordonIf the database server goes down and there is no code to hear it, does it
really go down?
<esc>:wq<CR>
I guess I'm missing the point on this. We all know hosting companies are
slow to adopt our changes. But does it really have anything to do with the
time interval between our releases. I would think the more pressing issue
would be BC which is not a function of the time interval but rather a
function of actual changes implemented in a release. I don't remember any
one in this thread insinuating that we'll be making diversions from the long
lasting goal of maintain BC whenever it's even remotely possible.
Best case scenario when only considering the time interval. We see a little
better adoption if short release cycles mean a new release gets push prior
to a hosting company's evaluation period for rollout changes.
Worst case scenario, a perception is generated by the fact we appear to be
moving ahead faster and they appear to be falling behind even faster. But I
think the reality will be that we are still doing roughly the same amount of
changes either way. We'll just be pushing it out in smaller chunks.
Eric Lee Stewart
When significant releases are 2-3 years apart, web hosts can expect to
have to
put in actual work every couple of years and mass-market developers can
expect
to have to beat their hosts over the head with a stick every few years.
If
significant releases are going to be every year, then it has to still
be
easy
and safe for hosts to upgrade. Preferably it has to also make servers
faster
because then they have an incentive to upgrade themselves. If hosts
don't
upgrade, it doesn't matter what amazing new features PHP has. Most
people
can't use 'em.I'm not against a more planned, frequent release cycle but I want to
make
sure
that the upgrade treadmill is kept walkable or else it won't matter
that
PHP
has new features.I think that the hosting companies will adapt as slow as they can, so
if we give more frequent releases, then they will (have to) upgrade
more often.
Additionaly if we release more frequently but with fewer changes, then
the developers can adapt more easily, because they have to watch out
for one or two change at a time, not a whole lot of changes.Being a guy who both runs a small hosting shop and spends lots of time
doing
development. I would greatly appreciate more frequent, but smaller
releases. I just finally got 5.3 rolled out this week, and have been
wanting it for months for the performance improvements in realpath, but
have
been hindered by the large list of things it would throw warnings about.
The other side of hosting is that most of your clients don't keep on top of
versions of their installed software. Even app developers don't want to go
make changes to a 5 year old app just because PHP has decided that
something
is no longer a good practice. My guess is that I'm in the minority of
hosts
that want to upgrade PHP for new features. Part of that is probably driven
by being a app developer for most of my job.--
-Nathan GordonIf the database server goes down and there is no code to hear it, does it
really go down?
<esc>:wq<CR>I guess I'm missing the point on this. We all know hosting companies are
slow to adopt our changes. But does it really have anything to do with the
time interval between our releases. I would think the more pressing issue
would be BC which is not a function of the time interval but rather a
function of actual changes implemented in a release. I don't remember any
one in this thread insinuating that we'll be making diversions from the long
lasting goal of maintain BC whenever it's even remotely possible.Best case scenario when only considering the time interval. We see a little
better adoption if short release cycles mean a new release gets push prior
to a hosting company's evaluation period for rollout changes.Worst case scenario, a perception is generated by the fact we appear to be
moving ahead faster and they appear to be falling behind even faster. But I
think the reality will be that we are still doing roughly the same amount of
changes either way. We'll just be pushing it out in smaller chunks.Eric Lee Stewart
The point is that, for instance, PHP 5.3 was not a trivial upgrade for
coders or hosters. Sure it's mostly compatible, and you certainly can
write code that works from 5.0->5.3 just fine, and if not then you're
probably doing something wrong... but that's most of the PHP code out
there right now. :-) And naturally you can't test your code against 5.3
until it's out.
So things like "this didn't used to throw a warning but should have all
along, so now it does" are BC breaks, from a hoster's point of view. If
they upgrade, some of the random code they host will start throwing
warnings when it didn't used to. So they don't upgrade, and Linux
distros take their time (not everyone is as behind as Red Hat, but the
current Ubuntu stable still ships 5.2 for instance), so devs who don't
compile their own PHP can't really test on 5.3... Nastiness. That's
what kept PHP 5 back for so long.
I guess my point is that one rough upgrade every 3-5 years is something
hosts and coders can deal with, mostly. Or one easy upgrade every 1-2
years is something hosts and coders can deal with, mostly. But a rough
upgrade every 1-2 years is not something that most hosts and coders can
keep up with. And the definition of "rough" in this context is really
strict.
So if non-bug releases are going to move from 3-5 years to 1-2 years, it
also needs to be kept easy, not rough, which means a much tighter reign
kept on BC breakage, even low-level "you should be doing it this way
now" breakage. The long-tail of versions that mass-market projects need
to support is then much longer, too, so they need to be able to write
code that will run smoothly on 5.2, 5.3, 5.4, and 5.5, even if they
don't use anything not in 5.2.
Does that explain my concern better?
--Larry Garfield
The point is that, for instance, PHP 5.3 was not a trivial upgrade for coders
or hosters. Sure it's mostly compatible, and you certainly can write code
that works from 5.0->5.3 just fine, and if not then you're probably doing
something wrong... but that's most of the PHP code out there right now. :-)
And naturally you can't test your code against 5.3 until it's out.
Sure you can, there are SVN snapshots and release candidates. We release
those so that you can test your code!
regards,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
I propose that sort of a
unicode working group forms but much less formal than what I make it
sound like. I think the discussions can remain on internals@ and
hopefully alternative approaches will be documented as RFCs. But what
I mean with working group is a list of a handful of names who feel
responsible to keep this topic moving until a solution is found and
who people know they can contact if they want to chat or whatever.So how would that "group" differ from just internals@ ?
hmm i think i specifically addressed this in my previous email:
"But what I mean with working group is a list of a handful of names
who feel responsible to keep this topic moving until a solution is
found and who people know they can contact if they want to chat or
whatever."
so i want to make sure that a handful of people feel responsible to
drive this thimg forward as its a topic that requires a fair bit of
research. of course anyone can contribute at anytime as well and with
thid group they also have people they can contact to be brought up to
speed quickly via a chat or phone call.
regards,
Lukas