Wei,
Currently, ACS follows the semantic version [1], which specifies that
introducing incompatibilities requires a new MAJOR version; therefore,
the few changes I mentioned would already require a new MAJOR version,
as they would generate incompatibilities. Also, remember that they are
some examples; there is a lot more to do. Adding functionalities in a
backward compatible manner, like we have been doing, requires only the
MINOR version change. Therefore, we have to understand the technical
reasons for the proposal and what we expect from it before deciding
anything.
Best regards,
Daniel Salvador (gutoveronezi)
[1] https://semver.org/
On 1/26/24 09:44, Wei ZHOU wrote:
Hi Daniel,
These are not big changes. You can fix them in some major/minor
releases, if you like.
I think we will not have a 5.0 release. If so, why not remove "4." from the
version which is useless at all.
Kind regards,
Wei
On Thu, 25 Jan 2024 at 15:52, Guto Veronezi <gutoveron...@apache.org> wrote:
Hello guys,
It is nice that we are discussing this topic; however, what is the
point? Is it just a semantic change? Or we will be able to introduce
changes that cause incompatibility between versions (although some
incompatibilities are already introduced even when they should not)? By
the way, I already have in mind some changes that would cause
incompatibilities between versions; some of they are:
- unifying duplicated APIs, like the "list*Metrics" APIs; it should be a
single parameter in the existing API, not a whole new API;
- renaming misleading APIs, like "createCondition" and others from the
AutoScale group that are not intuitive;
- standardize the APIs' response names, vide PR #7022 [1];
- and so many other disruptive changes.
If it is just a semantic change, then it does not make sense. We would
just make a show off to the community, but nothing would change at all.
What are the technical reasons between the proposal?
Best regards,
Daniel Salvador (gutoveronezi)
[1] https://github.com/apache/cloudstack/pull/7022
On 1/24/24 09:45, Wido den Hollander wrote:
Op 24/01/2024 om 10:47 schreef Daan Hoogland:
personally I don't like the months too much. They tie us down to a
release schedule that we have proven not to be able to maintain. a
year as number restricts us to just one major release that year, i.e.
only one moment for new integrations or major features. S I am for the
more liberal 20.x and if we make a second one some year we can freely
add a number.
Our mails just crossed :-) Timing!
Does YYYY.MM tie you down to a specific schedule? You can release
whenever you want, right? The version depends on when you release.
But I'm ok with just going with an number. 24, then 25, then 26, etc.
Something else then 4.x for ever.
Wido
On Wed, Jan 24, 2024 at 12:27 AM Wei ZHOU <ustcweiz...@gmail.com>
wrote:
Yes, the ubuntu version naming is the best in my opinion.
Other than the version naming, we need to decide the frequency of major
releases and minor releases, which version will be LTS, how long the
LTS/normal version will be supported, etc.
Maybe a vote in the dev/users/pmc mailing list?
在 2024年1月23日星期二，Nicolas Vazquez <nicolas.vazq...@shapeblue.com>
写道：
I like this idea as well, even if its YYYY.MM or YY.MM.
Would we want to define delivery months for releases similar to
Ubuntu .04
and .10?
Regards,
Nicolas Vazquez
________________________________
From: Nux <n...@li.nux.ro>
Sent: Tuesday, January 23, 2024 6:11 PM
To: dev@cloudstack.apache.org <dev@cloudstack.apache.org>
Cc: Wei ZHOU <ustcweiz...@gmail.com>
Subject: Re: [PROPOSAL] version naming : drop the 4.
An interesting proposition, I like it.
It would also relieve us from having to come up with any over-the-top
feature or change for a major version change.
On 2024-01-23 14:49, Wido den Hollander wrote:
We could look at Ubuntu, and other projects, and call it 2025.01
if we
release it in Jan 2025.
A great post on the website, mailinglists and social media could
explain the change in versioning, but that the code doesn't change
that
much.
Project has matured, etc, etc.
