Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Wed, 15 Jun 2016 09:54:55 +0200 (CEST)
From: Wido den Hollander <wido@widodh.nl>
To: dev@cloudstack.apache.org, John Burwell <john.burwell@shapeblue.com>
Message-ID: <1562817205.1955.1465977296131@ox.pcextreme.nl>
In-Reply-To: <A603724C-7F6B-42BB-AC11-332F3D810265@shapeblue.com>
References: <A603724C-7F6B-42BB-AC11-332F3D810265@shapeblue.com>
Subject: Re: [DISCUSS] 5.0.0 and 6.0.0
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Medium
archived-at: Wed, 15 Jun 2016 07:55:02 -0000

You really like typing long e-mails! :)

> Op 15 juni 2016 om 2:39 schreef John Burwell <john.burwell@shapeblue.com>=
:
>=20
>=20
> All,
>=20
> We have been discussing whether or not the next release would introduce t=
he need to increment the major revision number from 4 to 5 (i.e. become 5.0=
.0).  While I think we are very close to the time to have a 5.0.0 release, =
I don=E2=80=99t think the next release will introduce any backwards compati=
ble changes that necessitate.  However, Wido has brought two important ques=
tions =E2=80=94 What are our goals for a 5.0.0 release? When do we think we=
 should target its release?  I think we should address and gain consensus o=
n these issues now rather than allow circumstances to answer them for us.
>=20
> Since I joined the community (back in the 4.1.0 days), 5.0.0 was a mythic=
al, someday release when CloudStack would have a perfect architecture, buil=
d process, etc. -- a unicorn jumping a rainbow.  I realize that I have fall=
en into the trap of seeing 5.0.0 as some endpoint of perfection rather than=
 an important milestone in the on-going improvement and evolution of the pr=
oject.  Thinking it about is the former rather than the later, I realize th=
at we have a legacy cruft that we need to discard in order to move forward =
and architectural design improvements that we must implement to address eme=
rging infrastructure requirements.  I think we would be wise to separate th=
ese two objectives into a 5.0.0 release (cruft removal/breaking refactoring=
s) and 6.0.0 (backwards incompatible architectural redesign).  Not only do =
I see this approach as a risk mitigation, but also as a way to deliver impr=
ovements to users and developers as quickly as possible.
>=20
> For 5.0.0, my thought is that we would target the following high-level ob=
jectives:
>=20
> * Drop Java7 and adopt Java8 runtime and language features
> * Drop support for any hypervisor versions no longer supported by their v=
endors or communities
> * Drop any plugins which are no longer maintained or for which the commun=
ity has no means to test
> * Drop support for any distributions no longer supported by their vendors=
 or communities

+1 to these points above.

> * Define an official support matrix for the project
> * Adopt a formal policy for sunsetting support of components based on the=
 end-of-life dates set by their vendors or communities
> * Refactoring/cleanup of various APIs
> * Embedded Jetty/uberjar/unified YAML file configuration
>=20

Not completely sure about a official support matrix, but I get the point.

> While I am sure there are more clean up items, the focus of the release w=
ould be to discard pieces that are in the way on further improvement.
>=20
> 6.0.0 would be released within 9-12 months of 5.0.0 =E2=80=94 giving the =
community time to build atop 5.0.0 to redesign/improve the architecture of =
the system.
>=20
> I would like to see 5.0.0 released by the end of 2016 or at the beginning=
 of 2017.  Based on the release plan I previously proposed, we would have t=
he following releases remaining in 2016 and in early 2017:=20
>=20
> * 4.10 releasing on or about 28 August 2016
> * 4.11 releasing on or about 23 October 2016
> * 4.12 releasing on or about 18 December 2016=20
> * 4.13 release on or about 5 February 2017
>=20
> 4.12 seems to be the sweet spot in the schedule to cut the 5.0.0 release =
described above.  It would give us sometime to plan and gain consensus arou=
nd the changes in both the user and dev communities.  It would also allow t=
he second LTS release to be based on 5.0.0 =E2=80=94 allowing both release =
cycles to take advantage of the reduced support requirements and Java8 lang=
uage features. Based on this proposal, the releases above would change to t=
he following:
>=20
> * 4.10 releasing on or about 28 August 2016
> * 4.11 releasing on or about 23 October 2016
> * 5.0.0 releasing on or about 18 December 2016=20
> * 5.1.0 release on or about 5 February 2017
>=20

My question is mainly who is going to support all versions and maintain the=
m. Developers like to work on the newest stuff, so we get back to the LTS v=
ersion. Person A fixes something in 5.0 and doesn't want/like to backport i=
t to 4.X, what happens?

I'm all in favor of a 5.0 release, but we get back to the previously discus=
sed topics around a LTS and the different views on that.

> 6.0.0 would be targeted for release in 4Q2017 =E2=80=94 providing 9-12 mo=
nths to design and implement architectural improvements.
>=20

I think that 6.0 is to close, 9 months is not a lot of time for us at the m=
oment.

> Thoughts?  Other paths to 5.0.0 and beyond?
> -John
> john.burwell@shapeblue.com=20
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
> @shapeblue
>=20
>