Hi Daniel, The website/repository you mentioned was originally by a person, after CloudStack 2.x/3.x was released. Is there a decision we must/should follow ?
If you look around, most OS/software do not follow it. iOS/Android? Ubuntu/Debian/RHEL/Windows ? or Chrome/Firefox ? or kvm/vmware/xenserver ? By the way, the article is incorrect. Softwares must keep backward compatibility as much as possible. -Wei On Fri, 26 Jan 2024 at 17:32, Guto Veronezi <gutoveron...@apache.org> wrote: > 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. > >>>>>> > >>>>>> > >>>>>> > >>>> > >>>> >
