All,

Completely agree with Daan.  Per semantic versioning, a major revision increase 
must introduce a backwards incompatible change in the public API, removal of 
one of more supported devices, reduction in the list of supported 
distributions.  I agree that when we require Java8+, drop Ubuntu 12.04 support, 
drop support for an old hypervisor version, etc,  we will need to increment the 
major revision to reflect the fact that the release is not backwards compatible.

For 4.10 and LTS 4.9.0_1, I see it as critical that we support running on 
either Java7 or Java8.  In particular, producing an LTS release that only 
supports a JVM that has been unsupported for nearly 18 months would make it DOA 
in many shops.

It seems like it would make sense to have a 5.0.0 release that removed support 
for a number of legacy components (e.g. Xen 6.0 possibly 6.2, Java7, CentOS 5, 
etc), as well as, internal improvements (e.g. simplified configuration).  The 
focus of this release would be to reduce the footprint of codebase, as well as, 
make a set of backwards incompatible changes that further decouples plugins 
from core.  We would then plan for a 6.0.0 in 4Q2017 to introduce further 
architectural changes and API revisions.  The advantage to this approach is 
that it breaks up the large refactorings and architectural design changes — 
allowing us to gain velocity by removing legacy components, reducing the risk 
of these changes, and providing user benefit earlier.  Based on the release 
plan I previously proposed we have the following releases remaining in 2016 and 
in early 2017: 

* 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 
* 4.13 release on or about 5 February 2017

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 around 
the changes in both the user and dev communities.  It would also allow the 
second LTS release to be based on 5.0.0 — allowing both release cycles to take 
advantage of the reduced support requirements and Java8 language features. 
Based on this proposal, the releases above would change to the following:

* 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 
* 5.1.0 release on or about 5 February 2017

I am in the process of moving my proposal into the wiki.  If this approach is 
acceptable, I will reflect it there, and open a thread to discuss 5.0.0.

Thanks,
-John


> 
john.burw...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London VA WC2N 4HSUK
@shapeblue


On Jun 14, 2016, at 2:02 PM, Paul Angus <paul.an...@shapeblue.com> wrote:
> 
> +1 Daan.
> 
> My recollection was that major version number changes were only to be 
> triggered by breaks in backward compatibility (API).
> 
> 
> Kind regards,
> 
> Paul Angus
> 
> paul.an...@shapeblue.com 
> www.shapeblue.com
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
> 
> 
> 
> -----Original Message-----
> From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] 
> Sent: 14 June 2016 14:47
> To: dev <dev@cloudstack.apache.org>
> Cc: Rajani Karuturi <raj...@apache.org>
> Subject: Re: 4.9+ release
> 
> You know that would require more then one byte for our minor version, Will.
> I would be very pleased to go to 5.0 before that time.
> 
> On Tue, Jun 14, 2016 at 3:43 PM, Will Stevens <wstev...@cloudops.com> wrote:
> 
>> Daan is just trying to get us to version 4.256.  :P
>> 
>> *Will STEVENS*
>> Lead Developer
>> 
>> *CloudOps* *| *Cloud Solutions Experts
>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw 
>> @CloudOps_
>> 
>> On Tue, Jun 14, 2016 at 9:41 AM, Daan Hoogland 
>> <daan.hoogl...@gmail.com>
>> wrote:
>> 
>>> -1 to what Wido said. None of those points warant a major release 
>>> number upgrade. these should all be in 4.10, -.11, -12 etc.
>>> 
>>> major incompatibilities like API refactor, dropping backend support 
>>> for this or that hyporvisor or DB refactor are the things that 
>>> warrant 5.0, IMNSHO
>>> 
>>> On Tue, Jun 14, 2016 at 1:13 PM, Will Stevens 
>>> <williamstev...@gmail.com>
>>> wrote:
>>> 
>>>> +1. :)
>>>> On Jun 14, 2016 5:07 AM, "Wido den Hollander" <w...@widodh.nl> wrote:
>>>> 
>>>>> 
>>>>>> Op 14 juni 2016 om 10:55 schreef Rajani Karuturi <
>> raj...@apache.org
>>>> :
>>>>>> 
>>>>>> 
>>>>>> 4.10 or 5.0?
>>>>>> 
>>>>> 
>>>>> I would say 4.10
>>>>> 
>>>>>> We are in the 4.* release cycle from a long time.
>>>>>> Just wanted to check if anyone is planning on major changes 
>>>>>> which
>>>>> warrants
>>>>>> 5.0
>>>>>> 
>>>>> 
>>>>> 5.0 should imho be:
>>>>> 
>>>>> - Java 8
>>>>> - Ubuntu 16.04 / systemd support
>>>>> - Drop support for older libvirt versions (KVM)
>>>>> - Some killer feature(s)
>>>>> 
>>>>> Wido
>>>>> 
>>>>>> ~Rajani
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Daan
>>> 
>> 
> 
> 
> 
> --
> Daan

Reply via email to