Hello, Rohit
I'm very sorry to hear that your country is at war. Do you think that if
we extend the voting to a full week, you can participate?
Regarding your comments:
1. Semver is very specific on how the version naming should be; it
should only contain three version numbers, not four. Furthermore, adding
breaking changes on minor versions is very much not following semver. I
would like to start using semver, but for this, we must change our
current processes and practices. This is why this thread was created.
2. Regarding the deprecation, we have a process, but it allows removing
features on minor versions; thus, it does not follow semver.
3. Regarding database changes, the proposal being voted is very clear
that there might be exceptions for security changes that necessitate
database schema changes. Regarding changing the database schema in minor
versions, I believe it is in the user's best interest to have such a
guarantee; this way, upgrading/downgrading from minor versions inside
the same major would pose no issues to the DB. Moreover, we should not
confuse DB schema changes with DB data changes (e.g.
inserting/removing/altering something in the database to normalize some
inconsistency)
Best regards,
João Jandre
On 5/8/25 09:42, Rohit Yadav wrote:
Sorry all - I'm busy at work but want to chime in after considering the thread
(plus my country's at war atm). I need more time and I wouldn't be able to vote
within 72 hrs.
On the face value - none of the three things needs voting on, we already use the semver
& have used deprecation process for components already, and I don't think it's in
community's best interest to lose the ability to deliver database-changes in
maintenance/minor & security releases.
Regards.
________________________________
From: João Jandre <j...@apache.org>
Sent: Wednesday, May 7, 2025 22:40
To: dev@cloudstack.apache.org <dev@cloudstack.apache.org>
Subject: Re: [Discussion] Versioning
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
