Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C2BF018462 for ; Sun, 10 Jan 2016 21:03:09 +0000 (UTC) Received: (qmail 93781 invoked by uid 500); 10 Jan 2016 21:03:08 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 93646 invoked by uid 500); 10 Jan 2016 21:03:08 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 93620 invoked by uid 99); 10 Jan 2016 21:03:08 -0000 Received: from Unknown (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 10 Jan 2016 21:03:08 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id BDCF1C2C3D; Sun, 10 Jan 2016 21:03:07 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=6.31 tests=[URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id leUJM7NQoVwx; Sun, 10 Jan 2016 21:02:59 +0000 (UTC) Received: from ns2.ngine.ch (ns2.ngine.ch [151.236.17.33]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTP id C8E2025331; Sun, 10 Jan 2016 21:02:58 +0000 (UTC) Received: from web01.ngine.ch (web01.ngine.ch [37.139.11.202]) by ns2.ngine.ch (Postfix) with ESMTP id EE0D18239F5; Sun, 10 Jan 2016 22:02:50 +0100 (CET) Received: from [192.168.123.40] (41-47-239-77.dyn.cable.fcom.ch [77.239.47.41]) (Authenticated sender: mail@renemoser.net) by web01.ngine.ch (Postfix) with ESMTPSA id 0C9CE82DD9; Sun, 10 Jan 2016 21:02:52 +0000 (UTC) Subject: Re: LTS release or not To: users@cloudstack.apache.org, dev@cloudstack.apache.org References: <56918EE8.90102@renemoser.net> From: Rene Moser X-Enigmail-Draft-Status: N1110 Message-ID: <5692C651.9060503@renemoser.net> Date: Sun, 10 Jan 2016 22:00:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Daan Have not yet decided which version, but fixes will be backported into LTS not the other way around. But I see what you mean. The code base may have much diverted before 4.7 right? It is not really a problem. It only means more work (argh...). Sooner or later this will happen for every release we choose. I would like to use 4.5 for several reasons, one obvious is, that we know that it is in production on several clouds, including us. On 01/10/2016 12:40 PM, Daan Hoogland wrote: > Rene, I would advice to support 4.7 as LTS. It adheres to the new > development/release process unlike 4.5 and any bugfixes there can > automatically be merged forward to newer releases to reduce the chance of > regression. > > I am in favour of the general concept. > > On Sun, Jan 10, 2016 at 12:12 AM, Rubens Malheiro > wrote: > >> +1 >> Em 9 de jan de 2016 8:55 PM, "Rene Moser" escreveu: >> >>> Hi >>> >>> I recently started a discussion about the current release process. You >>> may have noticed that CloudStack had a few releases in the last 2 months. >>> >>> My concerns were that many CloudStack users will be confused about these >>> many releases (which one to take? Are fixes backported? How long will it >>> receive fixes? Do I have to upgrade?). >>> >>> We leads me to the question: Does CloudStack need an LTS version? To me >>> it would make sense in many ways: >>> >>> * Users in restrictive cloud environments can choose LTS for getting >>> backwards compatible bug fixes only. >>> >>> * Users in agile cloud environments can choose latest stable and getting >>> new features fast. >>> >>> * CloudStack developers must only maintain the latest stable (mainline) >>> and the LTS version. >>> >>> * CloudStack developers and mainline users can accept, that mainline may >>> break environments but will receive fast forward fixes. >>> >>> To me this would make a lot of sense. I am actually thinking about >>> maintaining 4.5 as a LTS by myself. >>> >>> Any thoughts? +1/-1? >>> >>> Regards >>> René >>> >> > > >