Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52669
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
To: Ilia Alshanetsky <ilia@prohost.org>
Cc: Derick Rethans <derick@php.net>, PHP internals <internals@lists.php.net>
In-Reply-To: <BANLkTinC-yoaaGN0V-eeTgeAD9Hm8Qarcw@mail.gmail.com>
References: <BANLkTim2Tbw+9egfrmrYfeZfNNwYWcg4dg@mail.gmail.com>
	 <alpine.DEB.2.02.1106011230270.9040@whisky>
	 <BANLkTinC-yoaaGN0V-eeTgeAD9Hm8Qarcw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 01 Jun 2011 14:44:23 +0200
Message-ID: <1306932263.1952.112.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Final version, RFC release process
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
> > This variant is not workable, because there are (in the example) in 2014
> > *five* branches. Merging between those, manually and automatically is
> > going to be a major pain. I'd say we all rather want to focus our time
> > on fixes and new features; and not spend more time doing branch merging,
> > whatever tool we use for this.
> 
> This is similar to my initial point about the proposal. We need to
> figure out a way to have fewer active bug-fix branches, just because
> it make dev live very difficult. Derick I am not sure your example is
> much better, since you still have 4 active branches (if I am reading
> the diagram correctly). I think 3 active bug fix branches, with maybe
> 1 security fixes only branches is the most we should have.

I mentioned this before: I like the Ubuntu model:

* One development branch for the next version
* One current version
* One "long term" supported version

The current version is aimed to give early access to new features, to
avoid cases like traits which take years to come out while a bit more
conservative users (and maybe distros) may stay on the LTS. Once a new
"current" comes out there won't be fixes for the previous anymore.
Every n-th "current" release will be a long term supported (LTS) release
receiving only only only bug fixing and the older it gets the more
critical bugs, only. What "long term" means can be discussed.
It is open for discussion if a LTS version will directly terminate the
previous LTS version or whether an LTS version will be released instead
of an "current" version, so for one period there would be two LTS but no
"current" branch.

johannes