Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47442
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 83.243.58.134 as permitted sender)
To: Lukas Kahwe Smith <mls@pooteeweet.org>
Cc: Andi Gutmans <andi@zend.com>, Olivier Hill <olivier.hill@gmail.com>,  Derick Rethans <derick@php.net>, PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <D743FF3D-BF83-4725-9CC5-469AF8DF0142@pooteeweet.org>
References: <4B9926E8.4080202@lerdorf.com>
	 <alpine.DEB.2.00.1003131123540.4153@kossu.derickrethans.nl>
	 <dc2522541003131015k7f38c733i21b128529b578d3f@mail.gmail.com>
	 <698DE66518E7CA45812BD18E807866CE03ECF62E@us-ex1.zend.net>
	 <D743FF3D-BF83-4725-9CC5-469AF8DF0142@pooteeweet.org>
Content-Type: text/plain; charset="UTF-8"
Organization: php.net
Date: Sun, 21 Mar 2010 20:02:06 +0100
Message-ID: <1269198126.1575.49.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 6
From: johannes@php.net (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Thu, 2010-03-18 at 10:12 +0100, Lukas Kahwe Smith wrote:
> On 18.03.2010, at 06:55, Andi Gutmans wrote:
> 
> >> -----Original Message-----
> >> From: Olivier Hill [mailto:olivier.hill@gmail.com]
> >> Sent: Saturday, March 13, 2010 10:15 AM
> >> To: Derick Rethans
> >> Cc: PHP Developers Mailing List
> >> Subject: Re: [PHP-DEV] PHP 6
> >> 
> >> We need to focus on Unicode more than what some says, whether this
> >> means descoping the Unicode release or not. However, this means that
> > the
> >> development focus needs to be towards new features AND Unicode, not
> >> having the new feature branch, and the siberia branch with Unicode
> > support.
> > 
> > I think the key to rebuilding momentum in PHP development is to not try
> > and boil the ocean but to focus on "smaller" major releases. This would
> > enable us to manage a more predictable release cycle, lower the risk for
> > each release incl. better manage compatibility and increase motivation
> > for contributors as they know they can have an impact and if they can't
> > make one release they know the next isn't that far off (the latter also
> > eliminates pressure to push pre-mature functionality into a release).
> 
> Yeah, I wouldnt mind if we would aim for regular releases in late spring 
> early summer every year. This ensures that developers scratching their own 
> itch have a clear timeline by when their hard work can make it into a 
> stable release.

Two releases per year is what Ubuntu is doing and is fine for a desktop
system. Server admins (which are a large part of our target group) are
way more conservative about updating their systems all the time.

That said I generally like the Ubuntu model - having fixed release
cycles with short time supported versions (giving early access to new
features) and long time supported versions (every n-th release is
supported n short release cycles, every other release just up to the
next release)

I hold such a model actually way more interesting for contributors as
they can see their features in a timely manner after making it stable in
the wild. With the current model it can take years till a feature is
rolled out - which is frustrating for contributors.

johannes