Hi Rene,
Thank you for your input!
I mostly agree with your points on when DB/API changes may be made.
Also, we currently do not have a Alpha/Beta/Stable scheme for APIs as
far as I know, but it could be an interesting addition to the process.
I have added my latest explanation and points regarding this discussion
on the discussion thread (see
https://lists.apache.org/thread/j69ly666jqtzt972bvsngwj1msfmj14t). Since
this is a voting thread, I would like to kindly ask you to add your 2
cents on the discussion thread, see if what I proposed there is more
like what you are thinking.
Best regards,
João Jandre
On 5/14/25 15:26, Rene Glover Jr. wrote:
Should there be nuances on the DB and API changes to help the
conversation? A few thoughts:
- DB changes to add new required fields or tables can only be made in a
major release.
- DB changes to add new “optional” tables, new optional fields, new
required fields with defaults, and new views allowed in a minor releases.
- API changes requiring new required fields can only be made in major
releases.
- API changes removing fields or changing existing field validations that
restrict previously allowed input must be made I. A major release.
- API changes adding new optional fields to an existing API are allowed in
a minor releases.
- New APIs can be added to a minor release as long as the use of those APIs
is not required to use that major version of the product.
- security patches trump all these rules above a certain severity (?)
Additionally, we may also want to consider an API stability model:
- Alpha - API changes of any kind allowed in any release
- Beta - API changes of any kind allowed in any minor or major release
- Stable - API changes follow general rules (like defined above)
On Wed, May 14, 2025 at 2:26 AM Rohit Yadav <rohit.ya...@shapeblue.com>
wrote:
-1 (binding)
This is mainly due to the point that "Changes to the database schema
should be introduced only in major versions" — the definition of "major"
here (4.xx, 5.xx) is based on Joao’s interpretation, and the proposed
versioning approach isn’t well defined and is asked for a vote.
Additional notes:
On #1: No objection if the plan is simply to drop the "4." from versioning.
On #2: I believe it's in the community's interest to allow DB schema
changes in minor (ex: 4.19.x, 4.20.x), maintenance/patch (ex: 4.19.3,
4.20.1), and security releases when needed. Requiring a major version bump
(e.g., 4 → 5) each time there are schema changes feels overly restrictive,
especially when users can follow best practices such as doing DB backup (or
snapshot) when downgrades.
On #3: Already in effect.
We should evaluate proposals based on whether they serve the community’s
long-term benefit.
PS. I’ll try to revisit versioning and release policies in light of Joao's
intent in the coming weeks.
Best regards.
________________________________
From: João Jandre <j...@apache.org>
Sent: Saturday, May 10, 2025 16:42
To: dev@cloudstack.apache.org <dev@cloudstack.apache.org>
Subject: Re: [VOTE] Versioning process
Hi, Rohit, all
The last discussion thread was open for a week before the vote was
started and; before that, there were many discussion threads:
https://lists.apache.org/thread/hnzp6hnsjyj8593cf6tbgryt1s8z5glq
https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
https://lists.apache.org/thread/4zs8d15ghvvwwro46ry5zjf8fn8x0t88
https://lists.apache.org/thread/o6o9h3qp8gqrpq4v7o81tl6vp51tkjhg
https://github.com/apache/cloudstack/discussions/8970
https://lists.apache.org/thread/6v0w49gp0fwtp53so757mx6nf34vpg81
In the last thread, I took the feedback I got from the discussions and
proposed changes with that in mind. Furthermore, the few responses on
the last discussion were positive, which is why I opened the vote.
I see that you have stated your points in the discussion thread. We can
keep the discussion going next week, and I'll be closing this voting
thread.
Best regards,
João Jandre
On 5/9/25 00:54, Rohit Yadav wrote:
May I propose we hold the vote, this has three different topics being
considered which looks like still need to be discussed. Also we cannot vote
on some of the things whose details are yet to be completed defined and
proposed.
Regards.
________________________________
From: João Jandre <j...@apache.org>
Sent: Friday, May 9, 2025 12:21:22 AM
To: dev@cloudstack.apache.org <dev@cloudstack.apache.org>
Subject: Re: [VOTE] Versioning process
Hi Daan,
Regarding your first point, adding default values to the DB is different
from changing the DB schema. Changing the DB schema would be
creating/removing tables or creating/removing columns. Thus, adding new
values to tables would not be an issue. Would you like me to add this
definition to the vote?
Regarding the second point, I will add a exception for APIs. Regarding
DB changes I have already specified it in the original voting message.
Best regards,
João Jandre
On 5/8/25 09:47, Daan Hoogland wrote:
João,
I am completely +1 on item 3.
I am missing the exceptions that we need on both other issues.
- for DB we add hypervisor types in minor versions and those need DB
changes
- for both DB and API changes we make exceptions for security releases
given a rewording to include those, I would be completely +1 on your
proposal.
so for now -0.666...
I would still push back on incompatible changes on major releases btw.
I want users to be able to continue using ACS for all eternity ;) But
we can handle those with migration paths and those would become
regular discussions here at dev@.
On Wed, May 7, 2025 at 7:15 PM João Jandre <j...@apache.org> wrote:
Hello, all
I am starting this voting thread regarding the discussions made in
https://lists.apache.org/thread/4jk31krsjl8cbp5n8wbt7ypwl65g364j. To
be
specific, these are the changes that we are going to vote on to follow
during our release process:
1. API Changes: Any changes to APIs that break backwards compatibility
should only be made in MAJOR versions. Currently, these would be our
5.x.x, 6.x.x, etc.. After this thread is finished, I will start another
thread regarding our version naming.
2. Database Schema: Changes to the database schema should be introduced
only in major versions. The only exception is for potential security
changes that require database changes; we never had such cases, and
when
(if) it appears, we will properly communicate it to operators/users of
ACS.
3. Feature Removal: 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 at least 6 months in advance in a previous version.
Vote will be open for 72 hours.
For sanity in tallying the vote, can PMC members please be sure to
indicate "(binding)" with their vote?
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)
