Well, I'm glad the topic raised the discussion. That's great. My point is
very carefully explained by Rohit. It's not a new idea - CloudStack
community is small. Some features are abandoned and broken because of no
developers behind them. I bet certain features still not tested in 4.11.2
because nobody uses them. When the feature owning vendor leaves the support
it's no way just to remove the feature like Midonet as Rafael said.

When I started the career, people used Perl5 and everyone was happy, but
Larry Wall decided to go to Perl6... And who knows where the Perl now?
People don't want something new because it's just renovated. Frankly, I
don't believe that deep CloudStack redesign could be delivered by the
community. But I believe CloudStack could evolve gradually, introducing new
features and fixing bugs. I believe, that if there is no vendor for
something it should be wiped out to keep the code sane and low fat. I don't
think it's right to push plugins into the upstream codebase. I think that
ACS community must keep eye on better features design and every version
must include one properly designed and voted feature aside of small
improvements and fixes. I believe that PRs must be moderated not only from
the code sense but also from the point that code is reflected in design
documents and documentation.

I don't think CS5 (deep redesign) is even required by users. The code is
pretty good, it works well. Just don't want to think it could end as Perl6.

чт, 24 янв. 2019 г. в 11:43, Rohit Yadav <rohit.ya...@shapeblue.com>:

> I'm in the favour of keeping the 4.x going because no API compatibility is
> broken, and as long as we are following semver there is no need. Calling a
> 4.x a 5.x just for the sake of bumping versions may cause some perception
> issue.
>
> Removal of unsupported/poc/incomplete features, plugins including APIs
> should not constitute breaking of compatibility. Several network and
> hypervisor plugins are still in poc/incomplete/unmaintained state.
>
> Unless the API layer, and perhaps DB layer is re-architected there is no
> point in calling the next version 5.x as long as semver is followed.
>
> In my opinion, the next major version 5.0 should have a restful versioned
> API layer, a new DB+upgrade framework that may support multiple db servers,
> a new UI, sandboxed plugin framework (right now a plugin can do anything it
> wants to say the cloud db), a new agent-clustering framework (the current
> low level nio and rpc code goes away), a distributed message bus and
> locking service (that we thought to introduce in 4.2,4.3 but incomplete),
> and refactor the networking/VR layer with a new VR. Not to mention cleanup
> some technical debt. The keywords being major architectural and
> api/integrational changes. Some of this maybe on-going, but we'll get to
> 5.x with patience over time.
>
> Regards,
> Rohit Yadav
>
> ________________________________
> From: Ivan Kudryavtsev <kudryavtsev...@bw-sw.com>
> Sent: Tuesday, January 22, 2019 9:15:29 AM
> To: users; dev
> Subject: Why CloudStack 5
>
> I decided whether to write it several weeks thinking about the stones and
> rotten potatoes, but still decided to do that. Hope it will not raise the
> stress level.
>
> Colleagues and ACS leaders, I would like to initiate the discussion. Why go
> to CS5 rather than stay with 4.XX. Some thoughts are:
>
> 1. According to the versioning guide, the first number stands for radical
> changes like if the community decided to go from current ORM to Hibernate.
> I don't see the capabilities for such changes and there are no intentions
> for the implementation.
>
> 2. I can realize that we 'stuck' with '4.XX' and the marketing can be
> disappointing from that point of view. Then, OK, let's just skip the first
> number "4." and release, ACS 13.X, 14.X, 15.X and so on. Every version will
> receive new impressing version number and everyone could be happy about
> that.
>
> Going to version "5" currently looks like as an intention to refresh but
> with very poor motivation. At least to me.
>
> The discussion is strongly welcome.
>
>
>
> --
> With best regards, Ivan Kudryavtsev
> Bitworks LLC
> Cell RU: +7-923-414-1515
> Cell USA: +1-201-257-1512
> WWW: http://bitworks.software/ <http://bw-sw.com/>
>
> rohit.ya...@shapeblue.com
> www.shapeblue.com
> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue
>
>
>
>

-- 
With best regards, Ivan Kudryavtsev
Bitworks LLC
Cell RU: +7-923-414-1515
Cell USA: +1-201-257-1512
WWW: http://bitworks.software/ <http://bw-sw.com/>

Reply via email to