Hi
Sorry for writing this topic to users but the dev mailing list is so too
noisy for me with git commits and PRs discussions, but that is another
topic...
On 21.05.25 18:57, Rohit Yadav wrote:
I may be missing something, but I haven't yet seen compelling reasons to change
my position. I encourage others—PMCs, committers, contributors, and users—to
share their views.
The issue I have with the current development process is that we
(community) think what the next version of cloudstack will be it's a
4.2x. But this thinking is somewhat wrong. It is anticipated.
We must think of it in a way that if we break anything, it's going to be
a major, e.g. it makes NO SENSE to have a development branch named the
next release of 4.2x. Otherwise there MUST NOT be any breaking changes
in it then. But we fail to not breaking it too often. That is why I
would even say that releases from a master/maim branch are always majors.
So, I agree with Joao's and Daniel's thoughts.
IMHO: DB schema changes SHOULD _generally_ be in major versions _except_
related to fixes --> patch releases (this is a very rare case anyway).
Data CAN be added in minor releases.
Anything (API, etc) that breaks MUST be in major.
Version number SHOULD be changed following SemVer, but I would prefer
starting with 5.x.x not 22.x.x but would not vote against 22.x.x.
Further, having this changed it, we SHOULD release _more often_ as it
would not make sense to just release majors. As a result, we agree to do
_more work_ with releases and backporting fixes and minors to a stable
branch.
Speaking of development, as a result of changing to SemVer I would also
suggest to change (back) to follow a "stable branches" development
process in our git repo. Devevelopment MUST be first made against master
branch (and not a 4.2x branch which gets merged to master):
- Development of next major MUST be in master/main branch
- Releases on master MUST be major.
- Fixes/Minors MAY get backported by chrerry picking to stable branches,
fixes SHOULD not be development in stable branches (except master branch
diverted too much)
- A stable branch SHOULD be created (stable-<major>) where minor and
patches for this branch go into (backports / cherry-pick)
Following this development process may also bring some benefits: We
COULD branch of to a stable branch once we agree the current state in
master is feature complete but not yet releasing it and stabilize and
test it while development in master branch is not blocked.
René
