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) > >>> > > > > > > > >
