Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (nike.apache.org: domain of runseb@gmail.com designates
 74.125.82.49 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [DISCUSS] LTS releases?
From: sebgoa <runseb@gmail.com>
In-Reply-To: <BF54D5F8-6F82-4ADD-9FA1-E3AB9F68545F@remi.nl>
Date: Fri, 3 Jul 2015 09:20:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CDCD5BE-A3AF-49B1-88F8-97F33D666E2B@gmail.com>
References: <559549F7.8090008@renemoser.net>
 <BF54D5F8-6F82-4ADD-9FA1-E3AB9F68545F@remi.nl>
To: dev@cloudstack.apache.org


On Jul 2, 2015, at 4:58 PM, Remi Bergsma <remi@remi.nl> wrote:

> Bug fixing in older releases is actually a lot of work. For security =
related issues we could maybe do it.=20
>=20
> Personally, I prefer to have a fast release cycle and smooth (tested) =
upgrade paths over 2-year LTS release cycle. It's more agile. As a =
bonus, people get the new features.=20
>=20
> The more people do upgrades that work (tm) the more confident they =
are. I'd really want to show that upgrades work so well that we need no =
LTS.=20
>=20
> But there might be other reasons people have where LTS would help. =
Please share!
>=20
> Regards, Remi=20

I think we got in a situation with 4.4 that called for us to keep =
maintaining 4.3=85.and even after 4.5 was released. Because 4.3 was seen =
as a good release.

Now that we have 4.4 and 4.5.2 etc, I don't think we will have the =
cycles to maintain that many release branches.

The big issue is upgrade path,=20

IMHO our LTS strategy is to have master as a release branch itself, =
adopt good practice to merge to master, have great upgrades and no =
regressions.

Ultimately we should divert our efforts to master.

So I am +1 with Remi on this.

>=20
>=20
>> On 02 Jul 2015, at 16:25, Rene Moser <mail@renemoser.net> wrote:
>>=20
>> Maybe a little bit off topic to the new release process, therefor a =
new
>> thread...
>>=20
>> speaking about releases. I just thought about supporting LTS =
releases.
>>=20
>> This would mean "someone" or "we" make a commitment to add bug fixes
>> (only) for a specified time. e.g. 2 years for a release or until the
>> next LTS release?
>>=20
>> Would this something anyone would be interested in?
>>=20
>> Yours
>> Ren=E9