Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49245
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain adamharvey.name from 209.85.160.42 cause and error)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <1281429940.969.2093.camel@guybrush>
References: <AANLkTinAy_93RNH85zLpGo11_2eBYBewxg+=KaPicX4e@mail.gmail.com> 
	<AANLkTi=Dv3AtH3BiTUgZwBuTLU30AF=3+5rr9aUUVzGG@mail.gmail.com> 
	<AANLkTi=o-ssPwwhO3naDC6B55=bD5uRGvUm+L30z8qGr@mail.gmail.com> 
	<1281429940.969.2093.camel@guybrush>
Date: Tue, 10 Aug 2010 17:25:43 +0800
Message-ID: <AANLkTin0umBnSXWdYUUJn551jBHtVvd9eRt8UGT5mpgt@mail.gmail.com>
To: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@php.net>
Cc: Pierre Joye <pierre.php@gmail.com>, Kalle Sommer Nielsen <kalle@php.net>, 
	Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] 5.4 Alpha?
From: aharvey@php.net (Adam Harvey)

2010/8/10 Johannes Schl=C3=BCter <johannes@php.net>:
> Yes. Release early, release often is a good thing. What I'd also like is
> to have a Ubuntu-like support model. Where we have one LTS (long term
> supported) version (now for instance 5.3) which will get bug fixes for
> quite some time and an "early access" version (5.4) which will receive
> updates until the next "early access" (5.5) is there.

I'm happy with the three branches idea, but I do have some concerns
about an LTS model:

=E2=80=93 The LTS branch is going to become more and more difficult to
backport fixes to as it diverges from the other two branches, and I
can see developers not bothering after a certain point, which may be
counter productive.

=E2=80=93 Documenting how functionality changes from version to version in =
the
manual is already a weak point, judging by some of the bugs and
feedback we get: users don't always grok the version bylines and
change log tables in the function reference as it is, and that's with
a more closely aligned set of active branches. We might end up needing
to rethink how we structure the manual by looking at something like
the Python approach of having separate manuals for separate versions,
which would require a not-insignificant amount of work.

=E2=80=93 It might be hard to communicate why 5.4 (in the example you
included) becomes end of lifed while 5.3 lives on. I guess that's no
different to Ubuntu, though.

=E2=80=93 Will downstream distributors want to ship non-LTS versions? This
might actually reduce the amount of useful feedback we get for (again,
using your example) 5.4, 5.5 and 5.6 releases, which might not be a
great thing for the stability of the next LTS (6.0) release.

> So we'd always have three branches, while two only receive bug fixes,
> plus one branch for the next milestone.

As I said, I have no qualms with this, particularly in light of some
of the articles that have been doing the rounds about 5.2's end of
lifing.* Under this system, and without an LTS structure, our current
situation would be a bit different, with both 5.2 and 5.3 getting bug
fixes until trunk is released (at which point 5.2 would be EOL), which
I think would suit users a bit better.

Adam

* Yes, I know it's not actually EOL, but that's been another
communication challenge.