Maybe it might be a good idea to keep 4.x for the version with no spec
which can be extended without regard for upward compatibility and start
a spec for 5.x. which would have some iron-clad rules about
compatibility and interface/API stability.
That way everyone could contribute to the version that they feel most
comfortable supporting.
Surely CS must be at a state by now where a really stable spec and API
could be documented in a short amount of time.
If there was a spec perhaps more developers would be able to contribute.
If the docs were simplified as a result of a cleaner spec, perhaps more
users would be able to get it implemented into production.
Even if it takes a few years to get a solid 5.0 out the door, it might
be worthwhile if that results in a product that can be marketed as a
mature product with clean rules for extensibility and customization.
In the meantime version 4 could be kept going if people want to keep
patching it and cleaning it up.
Every major software product reaches a point where the initial base and
layers of patches needs to be replaced by a version that is based on the
latest technology and development practices or it dies under its own weight.
From the discussion, it may be that CS has reached that point and it
would be a lot less work to do a major rewrite than to clean out the
accumulated junk.
I am not a CS developer and I find it hard to believe that CS is not yet
a sufficiently mature product providing a well understood functionality
that a really solid stable spec can not be developed.
Ron
On 1/25/19 9:36 PM, Ivan Kudryavtsev wrote:
Well, my intention is to prevent the community from doing revolutionary
changes intending to deliver redesigned 5.0, to keep going the current road
improving the codebase, removing the odd stuff like 'Citrix NetScaler',
'Juniper XYZ' if nobody supports them, improving current functionality and
adding new core features which are opensource without vendor lock-in, e.g.
SDNs (I know Wido is very into it) e.g. Cumulus infra support. I believe
current codebase is a pretty capable basement for future stable
functionality.
About new UI, etc stuff... Let's be honest. We develop CloudStack-UI
project for 1.5 years AFAIK. No single PR from other developers. Next,
Imagine, you have tree dedicated devs for CS5.X. Ok, it will take two years
to deliver new UI. Is it possible? NO.
Only gradual improvement can work for the current production team. We need
to put efforts to broaden the community, delivering the stuff which
helps new adopters to launch fast, e.g. as simple as Proxmox VE or oVirt or
VmWare ESXi. New users don't need much top-notch stuff, they need to
bootstrap fast.
сб, 26 янв. 2019 г. в 04:26, Rafael Weingärtner <rafaelweingart...@gmail.com
:
I am 100% with @Rohit Yadav <rohit.ya...@shapeblue.com> with respect to
4.12. I do diverge regarding the next LTS version though.
As you all guys said, the community is small, and as such, if we have the
requirement for multiple major changes, before upgrading the "X" bit in a
release, we will never go there (that is a fact). In my opinion, because
the community is small, we should look for a single major change (e.g. new
database upgrade method/scheme), and this should trigger the next major
release. The ability to upgrade the "X" bit free us to remove things such
as the basic network support (of course, we need to create a migration
path), new database scheme management method, normalize log messages and
logging framework and so on (many more issues can be listed here).
I really do not understand why we have so much resistance from some people
on this topic.
On Thu, Jan 24, 2019 at 2:27 PM Suresh Kumar Anaparti <
sureshkumar.anapa...@gmail.com> wrote:
Sounds good. Altogether, the makeover should be a new user experience and
leverage the latest hypervisor/storage tech and new/redesigned
frameworks.
-Suresh
On Thu, Jan 24, 2019 at 10:13 AM Rohit Yadav <rohit.ya...@shapeblue.com>
wrote:
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
--
Rafael Weingärtner
