Marco,

As I said in the 5.0.0 thread, I believe that we need to look upon 
architectural improvement as a continuous process.  We have been stymied for 
years around an analysis paralysis that holds that we must address 
architectural issue in 5.0.0.  I believe that we need to start with remove a 
significant amount of technical debt and cruft in 5.0.0 which will lay the 
foundation for larger architectural improvements later in 2017.

Thanks,
-John

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


On Jun 15, 2016, at 7:48 AM, ma...@exoscale.ch wrote:
> 
> Hi,
> 
> From my CS starter point of view, I agree with John's comment. I would really 
> like to see the next major version with a code & architecture clean-up, 
> especially producing a code architecture in the direction of the Java9 Jigsaw 
> modularity. It would be sad not to take the next specifications into account.
> For the dates, it's good to produce periodically a new release for the 4.X 
> but I don't see how putting one on the first 5.x version can be done before 
> defining what will be it.
> 
> Marco
> 
> -- To introduce myself, I joined Exoscale a few months ago to work on CS code 
> base to suit their needs.
> 
> 
>> On 15 Jun 2016, at 11:31, Rajani Karuturi <raj...@apache.org> wrote:
>> 
>> I like this discussion. But, my original question was not about what should
>> the next release number be?
>> 
>> i was checking if anyone working on anything big and hence want the next
>> release to be 5.0?
>> 
>> ~Rajani
>> 
>> <http://cloudplatform.accelerite.com/>
>> 
>> 
>> On Wed, Jun 15, 2016 at 12:29 PM, Daan Hoogland <daan.hoogl...@gmail.com>
>> wrote:
>> 
>>> maybe I should have answered here instead of the other thread :S
>>> 
>>> I am all with John on this. I can not judge the dates but the overall ideas
>>> are spot on.
>>> 
>>> I now see the API weren't mentioned in this thread I think they should.
>>> 
>>> On Wed, Jun 15, 2016 at 1:53 AM, ilya <ilya.mailing.li...@gmail.com>
>>> wrote:
>>> 
>>>> I agree and support John's comments below.
>>>> 
>>>> Regards
>>>> ilya
>>>> 
>>>> On 6/14/16 2:44 PM, John Burwell wrote:
>>>>> 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
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Daan
>>> 
> 

Reply via email to