On 3/19/10 10:34 AM, Eric Stewart wrote:
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>
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
