Rohit,
No problem, maybe my wording was not the best on that email. In any
case, I have sent a more detailed proposal and explanation on the
discussion thread and I am eager to hear back from the community :)
Best regards,
João Jandre
On 5/15/25 05:16, Rohit Yadav wrote:
Joao,
My bad, your email read to me that you "will be closing the voting thread" but it didn't
mention when. And, your email on the discussion thread suggested "voting is an important step
to formalize the changes", so I voted on the basis that the vote was still in play.
Regards.
________________________________
From: João Jandre <j...@apache.org>
Sent: Thursday, May 15, 2025 00:55
To: dev@cloudstack.apache.org <dev@cloudstack.apache.org>
Subject: Re: [VOTE] Versioning process
Hi, Rohit
In your previous message in this thread you proposed a hold on the vote.
In my reply I said that it would be closed since there was more
discussion to be made according to you. And now you are voting in the
same thread?
Can we continue the discussion on the discussion thread or is this your
final stance?
In any case, since the vote was closed I don't think we should be voting
in this thread. I'll open a new one with updated descriptions when it
seems like we are ready to vote again.
Best regards,
João Jandre
On 5/14/25 04:26, Rohit Yadav 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)
