Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50420
Return-Path: <johannes@schlueters.de>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 48712 invoked from network); 23 Nov 2010 09:32:15 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 23 Nov 2010 09:32:15 -0000
Authentication-Results: pb1.pair.com smtp.mail=johannes@schlueters.de; spf=permerror; sender-id=unknown
Authentication-Results: pb1.pair.com header.from=johannes@schlueters.de; sender-id=unknown
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
X-PHP-List-Original-Sender: johannes@schlueters.de
X-Host-Fingerprint: 217.114.211.66 unknown Solaris 10 (beta)
Received: from [217.114.211.66] ([217.114.211.66:53318] helo=config.schlueters.de)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 4C/CC-59959-41A8BEC4 for <internals@lists.php.net>; Tue, 23 Nov 2010 04:32:05 -0500
Received: from [192.168.1.29] (ppp-93-104-39-55.dynamic.mnet-online.de [93.104.39.55])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by config.schlueters.de (Postfix) with ESMTPSA id 7610146483;
	Tue, 23 Nov 2010 10:32:01 +0100 (CET)
To: Felipe Pena <felipensp@gmail.com>
Cc: internals <internals@lists.php.net>
In-Reply-To: <AANLkTi=ox5uUvEpo8ZuegpTPJLiS353Oqtud1WFGOPUT@mail.gmail.com>
References: <AANLkTi=ox5uUvEpo8ZuegpTPJLiS353Oqtud1WFGOPUT@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 23 Nov 2010 10:31:59 +0100
Message-ID: <1290504719.2294.251.camel@guybrush>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.2 
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Release Process
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

Hi,

On Mon, 2010-11-22 at 23:21 -0200, Felipe Pena wrote:
> With the recent chaos in the way we begin and ended releases, we would
> like to propose a clean way to deal with releases and related decisions: [1]

Thanks for preparing this. I have one change proposal:

With the proposed model it might, as you have illustrated, happen that
there are 5 versions being maintained.

As I mentioned multiple times on this list, on irc and other places I
like a Ubuntu-like model with two kinds of release which I, for the
purpose of this discussion, call "early access" (EA) and "long term
supported" (LTS) version.

At any given time only one EA may exist. When a new LTS version is being
released the previous LTS version enters security-only mode to give
users a transition period. Between every LTS version there are two EA
versions.

       2011        2012       2013         2014        2015        2016        2017
        |     |     |     |     |     |     |     |     |     |     |     |     |
LTS1    +++++++++++++++++++++++++++++++++++++-----------D     |     |     |     |
EA1     |     |     ++++++++++++D     |     |     |     |     |     |     |     |
EA2     |     |     |     |     ++++++++++++D     |     |     |     |     |     |
LTS2    |     |     |     |     |     |     ++++++++++++++++++++++++++++++++++++-----------D
EA3     |     |     |     |     |     |     |     |     ++++++++++++D
EA4     |     |     |     |     |     |     |     |     |     |     ++++++++++++D

The benefit is that developers and users who require a specific feature
get it early while distributors/hosters/software vendors/... have a safe
bet.

johannes