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) > > >
