(+ users) All,
Generally speaking, any versioning/styling change can be perceived as a big or concerning change by users (those existing or new ones trying/adopting). So, we must get our message across properly and correctly. I'm not for or against cosmetics change in versioning, but I'm really keen if we want to discuss if we can use this opportunity to streamline our LTS release, improve how we upgrade CloudStack (i.e relook at our DB/upgrade approach), make releases more linear and faster (avoid forking branches for example), and try to change new defaults and drop some old API/arch things (such as default API response type to json, but largely be backward compatible). Some of these suggestions may be too large an undertaking and make not be worth it. Overall, I've no objections if the consensus is to drop the "4." version prefix. I also want to hear from our users if they've any feedback for us. Regards. ________________________________ From: Guto Veronezi <gutoveron...@apache.org> Sent: Tuesday, February 13, 2024 18:34 To: d...@cloudstack.apache.org <d...@cloudstack.apache.org> Subject: Re: [PROPOSAL] version naming : drop the 4. Daan, As we still plan to introduce disruptive changes (in a cautious and structured way) in the major versions, all my concerns are met; I do not have further technical reasons to keep the "4.". Best regards, Daniel Salvador (gutoveronezi) On 2/12/24 11:55, Daan Hoogland wrote: > bump, > @Daniel Salvador is there any technical reason to keep the 4? any > reason why there must be a 5 instead of a 21, 22 or 23? We are > maintaining 4 number semantic versioning for no reason, as I see it. > > On Tue, Jan 30, 2024 at 12:02 PM Daan Hoogland <daan.hoogl...@gmail.com> > wrote: >> Daniel, "technical" reasons for dropping the 4 are all in the field of >> social engineering. In practice (as I think Wei also described) we are >> already treating the "minor" version number as major version. Since >> 4.0 or 4.1 (don´t remember) there has been renewed talk of a 5 , but >> never enough reason and or commitment to make it real. We could argue >> about it a lot. >> >> so >> ¨¨¨ >> The main point is: *we have to understand the technical reasons for >> the proposal and what we expect from it before deciding anything. >> ¨¨¨ >> The most important point is that we expect that people understand that >> we treat the number that now seems to be "minor" as major release >> numbers. >> >> >> On Fri, Jan 26, 2024 at 7:42 PM Wei ZHOU <ustcweiz...@gmail.com> wrote: >>> 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 >>> <stdin>: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 <gutoveron...@apache.org> 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) >>>> >>>> >>>> >> >> >> -- >> Daan > >
