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.
