Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:52670 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 97272 invoked from network); 1 Jun 2011 12:50:14 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Jun 2011 12:50:14 -0000 Authentication-Results: pb1.pair.com header.from=ilia@prohost.org; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=ilia@prohost.org; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain prohost.org designates 209.85.214.42 as permitted sender) X-PHP-List-Original-Sender: ilia@prohost.org X-Host-Fingerprint: 209.85.214.42 mail-bw0-f42.google.com Received: from [209.85.214.42] ([209.85.214.42:41982] helo=mail-bw0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7B/A6-61684-48536ED4 for ; Wed, 01 Jun 2011 08:50:13 -0400 Received: by bwz18 with SMTP id 18so12646bwz.29 for ; Wed, 01 Jun 2011 05:50:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.127.1 with SMTP id e1mr6880240bks.77.1306932608790; Wed, 01 Jun 2011 05:50:08 -0700 (PDT) Received: by 10.204.72.3 with HTTP; Wed, 1 Jun 2011 05:50:08 -0700 (PDT) In-Reply-To: <1306932263.1952.112.camel@guybrush> References: <1306932263.1952.112.camel@guybrush> Date: Wed, 1 Jun 2011 14:50:08 +0200 Message-ID: To: =?ISO-8859-1?Q?Johannes_Schl=FCter?= Cc: Derick Rethans , PHP internals Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] Final version, RFC release process From: ilia@prohost.org (Ilia Alshanetsky) Sounds reasonable. 2011/6/1 Johannes 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 20= 14 >> > *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 mergin= g, >> > 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 > > >