Re: [PROPOSAL] version naming : drop the 4.

[Daan Hoogland <da...@gmail.com>]

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 <da...@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 <us...@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 <gu...@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



-- 
Daan

Re: [PROPOSAL] version naming : drop the 4.

[Daan Hoogland <da...@gmail.com>]

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 <ro...@shapeblue.com> 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 <gu...@apache.org>
> Sent: Tuesday, February 13, 2024 18:34
> To: dev@cloudstack.apache.org <de...@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 <da...@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 <us...@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 <gu...@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
> >
> >



-- 
Daan

Re: [PROPOSAL] version naming : drop the 4.

[Daan Hoogland <da...@gmail.com>]

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 <ro...@shapeblue.com> 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 <gu...@apache.org>
> Sent: Tuesday, February 13, 2024 18:34
> To: dev@cloudstack.apache.org <de...@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 <da...@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 <us...@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 <gu...@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
> >
> >



-- 
Daan

Re: [PROPOSAL] version naming : drop the 4.

[Rohit Yadav <ro...@shapeblue.com>]

(+ 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 <gu...@apache.org>
Sent: Tuesday, February 13, 2024 18:34
To: dev@cloudstack.apache.org <de...@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 <da...@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 <us...@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 <gu...@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
>
>

Re: [PROPOSAL] version naming : drop the 4.

[Rohit Yadav <ro...@shapeblue.com>]

(+ 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 <gu...@apache.org>
Sent: Tuesday, February 13, 2024 18:34
To: dev@cloudstack.apache.org <de...@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 <da...@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 <us...@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 <gu...@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
>
>

Re: [PROPOSAL] version naming : drop the 4.

[Guto Veronezi <gu...@apache.org>]

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 <da...@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 <us...@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 <gu...@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
>
>