Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47421
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.178 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=BGfzkVh/3EkeKzv5bqX90xOdQkXnDckV03joE3y9n2Wg3RYbuxy3ho3g1nm5GrJXX9
         4yZ3+jpE0eKCixzHI6f1u9rBqSqdU5u7pLFefTNwU6ZfQSyRG+71+jm1yV9W8ecf5vhR
         otc6+eRLjixHNvT76qvQoggJ43+82NU2fpV/M=
MIME-Version: 1.0
In-Reply-To: <042C5521-4AE9-477A-B182-31D5FFE08207@pooteeweet.org>
References: <alpine.DEB.2.00.1003161545500.4153@kossu.derickrethans.nl>
	 <76412548-72DE-42D8-979D-9BD52AF754F8@pooteeweet.org>
	 <alpine.DEB.2.00.1003181658240.4153@kossu.derickrethans.nl>
	 <fe05d1541003181021v43bd130ao9febc20009bdfb6d@mail.gmail.com>
	 <slrnhq4prl.k2i.dsp@experimentalworks.net>
	 <042C5521-4AE9-477A-B182-31D5FFE08207@pooteeweet.org>
Date: Thu, 18 Mar 2010 23:05:39 -0400
Message-ID: <ce6b011c1003182005n7a2e31f8gc82dc9520684d2a6@mail.gmail.com>
To: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001636cd737f4484e404821e9f6a
Subject: Re: [PHP-DEV] PHP 5.4 branch and trunk
From: ericleestewart@gmail.com (Eric Stewart)

--001636cd737f4484e404821e9f6a
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 18, 2010 at 4:50 PM, Lukas Kahwe Smith <mls@pooteeweet.org>wrote:

>
> On 18.03.2010, at 18:48, David Soria Parra <dsp@php.net> wrote:
>
>  On 2010-03-18, Pierre Joye <pierre.php@gmail.com> wrote:
>>
>>> 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
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
+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

--001636cd737f4484e404821e9f6a--