Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65665
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain yahoo.de from 77.238.189.222 cause and error)
DomainKey-Status: good
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.de;
  h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=AVfkV93aa8M4SNzGEAKWF/1Ei0qfuD7OtzVXI3/eNyjsVrLlvo25t076GLq+hCVJ8iqDURyV6MmIzhyoEgK1I0YtzxavgKBJMjlOeP8UYClpk1CN2+K0lLAVaC4YvBC+BHKB66fUEhldpjdsmynAOg6uJluI4BZh6HuL3thHOl8=;
References: <CAOfzkkz3DC+aVb4c73QHGRzZv=1z=nG4uexdJh2n8h3ATGBBOA@mail.gmail.com> <CAEZPtU6UdX4uyR7tLomi==DNbmJduHoxa=qmb+dd2bJQKcoxjw@mail.gmail.com> <CAOfzkkwQNKRrX+MQ3JutkVWmHsCLZetJMp7AubA52E+=MSCcXw@mail.gmail.com> <510EBF98.4060900@lerdorf.com> <CAOfzkkwU4=K86582q1kgh_w2Ecubxij-ExecBLF_aHEWMY=dew@mail.gmail.com> <CAKOpQSyuKoSY8JGNhYUxPNTECR30Kk8j8MY5r4tY0qS_xBju2A@mail.gmail.com> <CAOfzkkwLODYXEyzEb1uNp6+ANUSZ9w80p3L7S5YoT6iGA1zRhA@mail.gmail.com> <5110AFFB.8040303@lerdorf.com> <5110BF7F.90508@lsces.co.uk>
Message-ID: <1360065708.95691.YahooMailNeo@web133004.mail.ir2.yahoo.com>
Date: Tue, 5 Feb 2013 12:01:48 +0000 (GMT)
Reply-To: hakre <hanskrentel@yahoo.de>
To: Lester Caine <lester@lsces.co.uk>,
  "internals@lists.php.net" <internals@lists.php.net>
In-Reply-To: <5110BF7F.90508@lsces.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Proposal for serious BC compatibility aka language versioning
From: hanskrentel@yahoo.de (hakre)

=0A=0A=0A=0A----- Urspr=FCngliche Message -----=0A> Von: Lester Caine <lest=
er@lsces.co.uk>=0A> An: "internals@lists.php.net" <internals@lists.php.net>=
=0A> CC: =0A> Gesendet: 9:14 Dienstag, 5.Februar 2013=0A> Betreff: Re: [PHP=
-DEV] Proposal for serious BC compatibility aka language versioning=0A> =0A=
> Rasmus Lerdorf wrote:=0A>>>  It would make everyone's life so much easier=
 if all the Drupal 8 =0A> code=0A>>>  >that is being written and tested wit=
h 5.4 would just work 5.5 =0A> without=0A>>>  >*any*=A0 problem.=0A>>  Yup,=
 so please test it against 5.5 now. Have you done so? It is rather=0A>>  tr=
ivial to do. Grab it from git or there is a tarball athttp://qa.php.net=0A>=
 =0A> Perhaps when I've finished the time machine ...=0A> =0A> In reality w=
e have to make choices where we DO spend time. There is still a mile =0A> o=
f code out there being used live which is running perfectly on the PHP5.2 =
=0A> infrastructure. That needs testing and reworking on PHP5.3 and then PH=
P5.4 =0A> before we get around to 5.5.=0A=0AWhy do you change the infrastru=
cture if the code does not need it? I mean, provide the infrastructure the =
code needs and done. There is more than one vendor that offers support for =
PHP 5.2 infrastructure in the market. What's the deal?=0A=0A> =0A> This is =
perhaps the main problem with accelerating the release timetable in that =
=0A> there simply is not enough time to bring everybody along? So something=
 has to =0A> give and at the moment for me it's going to have to be 5.5 ...=
 but by the =0A> time all the legacy stuff is up to 5.4 you will be way off=
 in the distance :(=0A=0AThere was no acceleration in the release timetable=
 from my point of view. The whole show was stopped between PHP 5.2 and 5.3.=
 This has been fixed now by explicitly having the one-year rhythm for major=
 releases again - documented publicly for the first time in PHP history (IR=
C). I like the idea to know that a new major is scheduled for the first of =
march. The equinox, can't you feel it? Would be great to know we get PHP 5.=
6 shipped until the next solar eclipse.=0A=0AAlso these yearly release peri=
od (the Rhythm) does not mean that it accelerated. It just helps you (and e=
verybody else) with dancing, coordinating and planning. E.g. you can choose=
 your speed by explicitly for example by leaving one major version out (ski=
pping it) because you know when you can expect the next major release - tha=
nks to rhythm - as well as you know how long it will be supported by the pr=
oject.=0A=0AWhen we got rhythm I can call my jamaican guy while being a sla=
ve to it. Grace Jones knew that. It's all leisure, no stress. The PHP userb=
ase just grew too large you can find a solution for everyone. Having a clea=
r release rhythm still helps everyone and looks like an appropriate tool to=
 me.=0A=0AAnd yeah, code, you need to refactor, always. We can't change tha=
t, nobody can. PHP might have made us lazy, which is fine, however, time go=
es by. Just some weeks ago I killed one of my PHP 5 babies (and it could ha=
ve run even longer technically, despite the PHP releases since it saw light=
 of day). The whole application is not needed any longer (thanks to the gre=
at improvements we have with frameworks and libraries since PHP 5.3 and 5.4=
). Don't work against the community, try to find good solutions of which ev=
erybody can benefit. Sure we all have issues, but the key point is to be fl=
exible with the solutions. Be it just taking the releases of PHP 5.2 suppor=
ted by third-party vendors or keeping up with the later stable leaving a ti=
me-window of three years to switch between one PHP version to the other. Ad=
ditionally if even this time-frame does not work out for more than *one* ve=
rsion change, you can even skip up to two major versions to keep up with th=
e
 rest of the gang to latest. I think it was never that easy as it is today.=
=0A=0A-- hakre=0A