Hello, René
I don't think you should apologize, we are a community after all, and we
are bound to disagree at some point. This discussion is very important
to this project and it will have to be made at some time in the future,
so why not now? As Pearl said, we will need time and effort to make a
decision that keeps the community and the project stable, whilst aiming
to innovate and bring more people to the project.
I agree with you René that we should create more major releases,
however, the discussion should not be in the naming convention, but in
the methodology of creating new Apache CloudStack versions. I think the
project would greatly benefit having well-defined criteria and standards
for the release process, which would impact in the naming convention per
consequence.
We already see default behaviors being changed in minor versions, and my
only problem with that, is that there are no criteria to when this is
accepted by the community. If we have a standard more similar to other
projects, e.g., major versions for breaking compatibility, we can
introduce breaking changes (when needed) and users would expect these
kinds of behaviors when updating to a new major version.
As a side note, on a marketing perspective, there are a lot of important
features released between the 4.16 and 4.20 that could have been a core
feature of CloudStack 5 and even CloudStack 6, for that matter. On my
perspective as a user of other tools, major releases receives more
attention than any mid/minor release, therefore, more major releases
would bring more users to the project, IMHO.
Best regards,
Bryan
On 11/12/2024 11:51, Rene Moser wrote:
.oO(...oh boy, what have I started...)
Although I'd like to see more ‘major releases’ where we show that
‘things’ can break, our release strategy and feature integration has
worked pretty well.
It looks silly to discuss weather 4.21 or 5.0. I just want to point
out that at some point between 4.21 and 4.99 we need to put 5 in
front, and maybe that's a chance to think about whether more major
releases would actually help show more clearly that things can break.
The ‘old school’ thinking that we need to make a ‘significant’ change
in e.g. ORM, or UI, or hypervisor to make a new major is not my opinion.
IMHO A major release shows one thing: "This could break existing
integrations, please test well."
As we don't do major releases, this now applies to our minor releases
and we have learnt to accept this. That is our legacy.
I'd like to ask everyone to gently calm down a bit and I am sorry for
"poke a wasp's nest"
Yours
René
