Re: [PROPOSAL] version naming : drop the 4.
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 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 .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 > 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 > >>> 写道： > >>> > I like this idea as well, even if its .MM or YY.MM. > > Would we want to define delivery months for releases similar to > Ubuntu .04 > and .10? > > Regards, > Nicolas Vazquez > > From: Nux > Sent: Tuesday, January 23, 2024 6:11 PM > To: dev@cloudstack.apache.org > Cc: Wei ZHOU > 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. > > > > > >> > >> > >> >
Re: [PROPOSAL] version naming : drop the 4.
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 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 .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 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 写道： I like this idea as well, even if its .MM or YY.MM. Would we want to define delivery months for releases similar to Ubuntu .04 and .10? Regards, Nicolas Vazquez From: Nux Sent: Tuesday, January 23, 2024 6:11 PM To: dev@cloudstack.apache.org Cc: Wei ZHOU 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.
Re: [PROPOSAL] version naming : drop the 4.
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 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 > 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 .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 > >> 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 > > 写道： > > > >> I like this idea as well, even if its .MM or YY.MM. > >> > >> Would we want to define delivery months for releases similar to > >> Ubuntu .04 > >> and .10? > >> > >> Regards, > >> Nicolas Vazquez > >> > >> From: Nux > >> Sent: Tuesday, January 23, 2024 6:11 PM > >> To: dev@cloudstack.apache.org > >> Cc: Wei ZHOU > >> 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 chan
Re: [PROPOSAL] version naming : drop the 4.
Exactly, so you understand now why we must discuss what we intend. Although, incompatibilities are needed sometimes so we can evolve, leaving old ways and deprecated technologies and techniques in the past. *The main point is: *we have to understand the technical reasons for the proposal and what we expect from it before deciding anything. Best regards, Daniel Salvador (gutoveronezi) On 1/26/24 13:50, Wei ZHOU wrote: 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 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 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 .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 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 写道： I like this idea as well, even if its .MM or YY.MM. Would we want to define delivery months for releases similar to Ubuntu .04 and .10? Regards, Nicolas Vazquez From: Nux Sent: Tuesday, January 23, 2024 6:11 PM To:dev@cloudstack.apache.org Cc: Wei ZHOU 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.
Re: [PROPOSAL] version naming : drop the 4.
Hi Daniel, If we are discussing 5.0, I would have the same concern as you. What we are discussing is dropping 4.x. The fact is, we will never release 5.0 (anyone disagree ?) In this case, the major version 4.x becomes useless. If we compare 4.20.0/4.21.0 with 20.0/21.0, it is obvious which is better. IMHO due to the similar reason, the Java version has been changed from 1.x to java 1.7/1.8 (=java 7/8) then to java 11/14/17. of course there will be some issues if semantic changes, I think it is under control. Regarding the compatibility, I think we can change the APIs gradually. I noticed the following recently when I tested VR upgrade to debian12/python3 root@r-431-VM:~# python Python 3.11.2 (main, Mar 13 2023, 12:18:29) [GCC 12.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import cgi :1: DeprecationWarning: 'cgi' is deprecated and slated for removal in Python 3.13 For the API changes you mentioned, we could try the similar - in version X, add new APIs, mark the old APIs as deprecated - tell users the old APIs will be removed in version Y, please use new APIs instead. - in version Y, remove the old APIs. This can be done in each major/minor release. No need to wait for 5.0. -Wei On Fri, 26 Jan 2024 at 18:51, Guto Veronezi wrote: > Exactly, so you understand now why we must discuss what we intend. > Although, incompatibilities are needed sometimes so we can evolve, > leaving old ways and deprecated technologies and techniques in the past. > > *The main point is: *we have to understand the technical reasons for the > proposal and what we expect from it before deciding anything. > > Best regards, > Daniel Salvador (gutoveronezi) > > >
