On Fri, Mar 2, 2012 at 13:34, Pierre Joye wrote:
> hi,
>
> It should have been done before 5.4.0 was out, but better late than never.
>
> I put together four options here:
>
> https://wiki.php.net/rfc/php53eol
>
> I'm in favor of option #1, as it gives enough time to our users to
> migrate by redu
Option #1 seems like a good way to go to me.
On Fri, Mar 2, 2012 at 7:34 AM, Pierre Joye wrote:
> hi,
>
> It should have been done before 5.4.0 was out, but better late than never.
>
> I put together four options here:
>
> https://wiki.php.net/rfc/php53eol
>
> I'm in favor of option #1, as it giv
hi,
On Mon, Mar 5, 2012 at 11:56 PM, Matthew Weier O'Phinney
wrote:
> I did, actually. I still agree with Sebastian's proposal. While the PHP
> group may want to push for faster adoption, the pattern I've observed
> over and over is that ISPs and distributions -- particularly those with
> LTS of
On 2012-03-05, Pierre Joye wrote:
> On Mon, Mar 5, 2012 at 9:53 PM, Matthew Weier O'Phinney
> wrote:
>
> > +1.
>
> Votes are for later.
This was an indication of being in favor of the proposal, no more, no
less.
> > Since so many distros and ISPs tend to adopt late, this would keep them,
> > an
On Mon, Mar 5, 2012 at 9:53 PM, Matthew Weier O'Phinney
wrote:
> +1.
Votes are for later.
> Since so many distros and ISPs tend to adopt late, this would keep them,
> and their users, covered for a reasonable time period, allowing for a
> cleaner migration path.
There is a clear migration path
On 2012-03-02, Sebastian Bergmann wrote:
> On 03/02/2012 07:34 AM, Pierre Joye wrote:
> > https://wiki.php.net/rfc/php53eol
>
> I discussed with Arne Blankerts and Stefan Priebsch over breakfast today
> and Stefan had an interesting idea: why not announce (now) that PHP 5.3
> will go into EO
Hi!
https://wiki.php.net/rfc/php53eol
I'm undecided between 1+2 and 2 for both. I guess it depends on adoption
of 5.4 and progress with 5.5...
Side note: looking at the new email subjects, spent some time wondering
why we have this huge thread discussing line endings on the list and
what'
Hi!
Would it be worth while to discuss the possibility of LTS releases
(Long Term Support) with 5 or 7 year support (from time of initial
release)...?
It is fine to discuss it and you can still support PHP 4 now if you want
to, but who's going to be doing it otherwise? I wouldn't really want
2012/3/2 Johannes Schlüter :
> So to sum it all up: I would prefer to promise security fixes only to
> the outside (2 years if people here think that's a good time) and then,
> as a group, agree to do additional bug fixing during that time.
So, to sum it one step further, option #1
--
Pierre
Kris Craig wrote:
I'm probably missing something, but why not just do it like we did with
5.2? I.e. we keep maintaining it until PHP 5.5, at which time we deprecate
it and be done with it?
Like I said, I'm probably missing something lol, so if someone could
explain why this is different I'd be
Hi,
the primary goal should be to encourage people to move to 5.4 as soon as
possible. The clear marketing message should be along the lines of "PHP
5.4 is the best version there is, it has all of 5.3's bug fixes and
additional improvements". We have to drive the 5.4 adoption.
I also don't think
Ok, I'm up to speed now. I agree that Option 1 is the best approach.
--Kris
On Fri, Mar 2, 2012 at 10:58 AM, Pierre Joye wrote:
> again, we have a clear EOL process now for 5.4 and later.
>
> Only 5.3 does not have any. We have to define it now instead of doing
> it in 1-2 years without givin
again, we have a clear EOL process now for 5.4 and later.
Only 5.3 does not have any. We have to define it now instead of doing
it in 1-2 years without giving our users any kind of reasonable delay
to plan a migration.
Cheers,
On Fri, Mar 2, 2012 at 7:54 PM, Kris Craig wrote:
> I'm probably mis
I'm probably missing something, but why not just do it like we did with
5.2? I.e. we keep maintaining it until PHP 5.5, at which time we deprecate
it and be done with it?
Like I said, I'm probably missing something lol, so if someone could
explain why this is different I'd be much obliged! =)
-
Excerpts from Sebastian Bergmann's message of Fri Mar 02 07:41:53 -0800 2012:
> On 03/02/2012 07:34 AM, Pierre Joye wrote:
> > https://wiki.php.net/rfc/php53eol
>
> I discussed with Arne Blankerts and Stefan Priebsch over breakfast today
> and Stefan had an interesting idea: why not announce (
hi Sebastian,
Thing is that we already have well defined lifecycle for anything
after 5.4. So the question is only about 5.3.
That's why, given that it is already a couple of years old, I would
rather go with a statically defined EOL now. As php-next is very
unlikely to be the moment where people
On 03/02/2012 10:54 AM, Pierre Joye wrote:
And when do you think it is one year after php-next? In two years. So
much about one year being the only option ;-)
I am capable of learning, but that's besides the point. The point is
static (two years after release) vs. dynamic (one year after next
they are totally unrelated. The discussion here is not about whether
next will be late but when 5.3 will end.
The key here is not the date itself but the ability for hosting
companies, distros, etc. to plan a migration or an EOL. One or two
months less or more do not change anything, as long as th
On Fri, Mar 2, 2012 at 5:06 PM, Pierre Joye wrote:
> On Fri, Mar 2, 2012 at 5:04 PM, Ferenc Kovacs wrote:
>
> > that's just the schedule
>
> Yes, and as of now this is the plan. The idea is the same, that does
> not affect the EOL of 5.3 is php-next is a month late, not at all.
>
>
yep, and I ex
On Fri, Mar 2, 2012 at 5:04 PM, Ferenc Kovacs wrote:
> that's just the schedule
Yes, and as of now this is the plan. The idea is the same, that does
not affect the EOL of 5.3 is php-next is a month late, not at all.
Cheers,
--
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.o
On Fri, Mar 2, 2012 at 4:54 PM, Pierre Joye wrote:
> hi Sebastian,
>
> On Fri, Mar 2, 2012 at 4:41 PM, Sebastian Bergmann
> wrote:
> > On 03/02/2012 07:34 AM, Pierre Joye wrote:
> >>
> >> https://wiki.php.net/rfc/php53eol
> >
> >
> > I discussed with Arne Blankerts and Stefan Priebsch over brea
hi Sebastian,
On Fri, Mar 2, 2012 at 4:41 PM, Sebastian Bergmann wrote:
> On 03/02/2012 07:34 AM, Pierre Joye wrote:
>>
>> https://wiki.php.net/rfc/php53eol
>
>
> I discussed with Arne Blankerts and Stefan Priebsch over breakfast today
> and Stefan had an interesting idea: why not announce (now
I like that. That way there will always be 2 stable maintained
versions, and possibly a third (depending on timing) that's security
only...
Solves the problem quite nicely IMHO...
Anthony
On Fri, Mar 2, 2012 at 10:41 AM, Sebastian Bergmann wrote:
> On 03/02/2012 07:34 AM, Pierre Joye wrote:
>>
On 03/02/2012 07:34 AM, Pierre Joye wrote:
https://wiki.php.net/rfc/php53eol
I discussed with Arne Blankerts and Stefan Priebsch over breakfast today
and Stefan had an interesting idea: why not announce (now) that PHP 5.3
will go into EOL a year after PHP 5.5 comes out?
* Now until PHP 5
Am 02.03.2012 15:15, schrieb Sebastian Bergmann:
On 03/02/2012 08:34 AM, Simon Schick wrote:
It's really hard to make a decision here because you also have to care
about big companies in one way, that have not updated to PHP 5.3 now
Such companies are using LTS releases of their OS distributio
On 03/02/2012 08:34 AM, Simon Schick wrote:
It's really hard to make a decision here because you also have to care
about big companies in one way, that have not updated to PHP 5.3 now
Such companies are using LTS releases of their OS distribution (RHEL,
SLES, ...) where the vendor will take c
On 03/02/2012 07:34 AM, Pierre Joye wrote:
https://wiki.php.net/rfc/php53eol
One year with bugs fixes (both security and normal bugs) seems to be
the only feasible option to me.
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/
Hi, all
It's really hard to make a decision here because you also have to care
about big companies in one way, that have not updated to PHP 5.3 now ...
But instead of that I read some posts from November last year that they
have PHP6 in their control-panel, what is basically PHP 5.4 beta ...
One
On Fri, Mar 2, 2012 at 2:43 PM, Adam Harvey wrote:
> On 2 March 2012 21:34, Simon Schick wrote:
> > One or two years is way to short if you'd ask me. A major release should
> be
> > supported with all kind of bug fixes for min. 3 years after a new release
> > has been brought out. Specially if i
On 2 March 2012 21:34, Simon Schick wrote:
> One or two years is way to short if you'd ask me. A major release should be
> supported with all kind of bug fixes for min. 3 years after a new release
> has been brought out. Specially if it's a wide-spread language like PHP that
> has been implemented
btw, thanks for those who keep the discussion focused on 5.3 EOL :-)
For the votes, the votes phase will begin next week :)
On Fri, Mar 2, 2012 at 2:12 PM, Adam Harvey wrote:
> On 2 March 2012 21:05, Gustavo Lopes wrote:
>> Fair enough. Option #1 seems the most appropriate then. The others seem
On 2 March 2012 21:05, Gustavo Lopes wrote:
> Fair enough. Option #1 seems the most appropriate then. The others seem too
> drastic to implement with such short notice.
+1. We can't drop bug fixes immediately without warning, and I don't
think the overhead of backporting security fixes is too one
On Fri, Mar 2, 2012 at 2:00 PM, Anthony Ferrara wrote:
> Would it be worth while to discuss the possibility of LTS releases
> (Long Term Support) with 5 or 7 year support (from time of initial
> release)...?
>
> 5.3 is 2.5 years old now. Which means depending on the option that's
> chosen here,
On Fri, 02 Mar 2012 14:00:51 +0100, Pierre Joye
wrote:
On Fri, Mar 2, 2012 at 1:56 PM, Gustavo Lopes
wrote:
I'd go with another option:
One year of bug fixes, one year of security fixes and bug fixes that are
trivial to backport.
Won't work. It is then two years bug fixing.
The idea
Hi,
We already discussed LTS
On Fri, Mar 2, 2012 at 2:00 PM, Anthony Ferrara wrote:
> Would it be worth while to discuss the possibility of LTS releases
> (Long Term Support) with 5 or 7 year support (from time of initial
> release)...?
>
> 5.3 is 2.5 years old now. Which means depending on the
On Fri, Mar 2, 2012 at 1:56 PM, Gustavo Lopes wrote:
> I'd go with another option:
>
> One year of bug fixes, one year of security fixes and bug fixes that are
> trivial to backport.
Won't work. It is then two years bug fixing.
The idea of security only is to reduce both the amount of work and
Would it be worth while to discuss the possibility of LTS releases
(Long Term Support) with 5 or 7 year support (from time of initial
release)...?
5.3 is 2.5 years old now. Which means depending on the option that's
chosen here, it'll be completely out of support a mere 3.5 to 4.5
years after ini
On Fri, 02 Mar 2012 13:34:21 +0100, Pierre Joye
wrote:
hi,
It should have been done before 5.4.0 was out, but better late than
never.
I put together four options here:
https://wiki.php.net/rfc/php53eol
I'm in favor of option #1, as it gives enough time to our users to
migrate by reduci
fixed
On Fri, Mar 2, 2012 at 1:45 PM, Keloran wrote:
> isnt option3 and option1 the same ? (unless i cant read properlly {very
> possible})
>
> On Fri, Mar 2, 2012 at 12:34 PM, Pierre Joye wrote:
>>
>> hi,
>>
>> It should have been done before 5.4.0 was out, but better late than never.
>>
>> I p
isnt option3 and option1 the same ? (unless i cant read properlly {very
possible})
On Fri, Mar 2, 2012 at 12:34 PM, Pierre Joye wrote:
> hi,
>
> It should have been done before 5.4.0 was out, but better late than never.
>
> I put together four options here:
>
> https://wiki.php.net/rfc/php53eol
Hi Pierre,
Option 1 and 3 are the same ;-)
Option 1
One year with bugs fixes followed by one year with security fixes only
Option 2
Two years with security fixes only
Option 3
One year with bugs fixes followed by one year with security fixes only
Option 4
One year with security fixes only
hi,
It should have been done before 5.4.0 was out, but better late than never.
I put together four options here:
https://wiki.php.net/rfc/php53eol
I'm in favor of option #1, as it gives enough time to our users to
migrate by reducing the maintenance period to only one year.
Suggestions or comm
42 matches
Mail list logo
