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