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.
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. > > > > > > > > -- Daan
