Hi everyone,
As it seems we have no objections to the proposed changes to our
versioning, I'll be starting a voting thread to vote on the changes to
the versioning process that were discussed on this thread.
Once the first subject is decided (the process to follow and guide the
release process), I'll start another thread regarding the versioning
naming/pattern we will adopt.
Please note that I'm proposing that these changes only take effect
**after** 4.21 is released.
Best regards,
João Jandre
On 4/30/25 16:06, João Jandre wrote:
Hi everyone,
I would like to revisit the topic of versioning, particularly in light
of our last discussion (see
https://lists.apache.org/thread/hnzp6hnsjyj8593cf6tbgryt1s8z5glq). It
seems that most people here agree with the idea of transitioning to a
new major version (e.g., from 4.x to 5.0), or at the very least, are
not opposed to it.
However, I believe there are still some misunderstandings about the
reasoning behind major version changes. The number itself is not that
important; the key point is to establish a clear system for
introducing changes that break backwards compatibility. As René
pointed out, we currently do not have a formal mechanism for handling
such changes. As a result, we frequently introduce breaking changes in
minor releases, which means operators need to be aware that upgrading
to a new minor version could potentially disrupt compatibility and
make their lives more difficult when they need to roll back to a
previous release after an upgrade (e.g. if a rollback is needed after
a few days of an upgrade).
A formal versioning strategy (defining what constitutes a major,
minor, patch, and security release) would help improve the project’s
stability. It would also allow us to plan major changes more
effectively and communicate them clearly to the community.
I am aware that there has been some hesitation about establishing a
release schedule. To avoid further complications, I won’t suggest one
here, at least not until we have automated the release process.
With that in mind, I propose that we start adhering to the semantic
versioning (semver) system that we have outlined in our documentation
(https://cwiki.apache.org/confluence/display/CLOUDSTACK/LTS and
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up).
According to our current definitions, we have not had a true major
release in over 10 years, even though we have introduced breaking
changes in multiple minor releases during that time.
To align with semantic versioning, I suggest the following changes to
our versioning practices:
- API Changes: Any changes to APIs that break backwards compatibility
should only be made in major versions (e.g., 5.x.x, 6.x.x, etc.).
- Database Schema: Changes to the database schema should also be
introduced only in major versions.
- Feature Removal: We need to update the process of feature removal
(see
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68720798)
to ensure that features are only removed in major versions, after
having been announced in advance in a previous major version.
If everyone agrees with this approach, we can begin following semantic
versioning after the release of 4.21. This means we would elect a
Release Manager for the next major as soon as 4.21 is out. If no one
is interested in being the RM for the next major, I'll put myself
forward to do it. Moreover, I would propose at least one major release
per year, and I (and the folks on our side here) would be willing to
put the effort into being the RM for these releases if needed.
Regarding the next major naming (e.g., 5.0, 2025.0, 22.0, etc.) we can
have a separate voting to decide on it.
Looking forward to your thoughts and feedback.
Best regards,
João Jandre
