Well, to all users@these lists,
please comment.
The ratio is that cloudstack is called cloudstack4 as an evolutionary
result from the development at cloud.com and citrix and that all
version since 4.0 (the apache podling version) are basically major
versions according to semantic versioning. Keeping the 4 as version
number has no technical meaning and obfuscates the true state of the
software.
The idea is that we drop the 4 at version 20 and continue as usual
with minor and patch level updates as we have in the past.
Not all of the discussion around this is included in this mail, but
you can find it at
https://lists.apache.org/thread/lh45w55c3jmhm7w2w0xgdvlw78pd4p87
*Any* feedback is welcome.
On Thu, Feb 15, 2024 at 12:01 PM Rohit Yadav wrote:
>
> (+ 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
> Sent: Tuesday, February 13, 2024 18:34
> To: dev@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
> > 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 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
> >>> :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
