What I am observing - and I am not commenting if this is right behavior or not - is that many companies still have not refactored their 2.7 project to 3.xx! But they have had many years to plan this?!? Maybe they do not care much of the potential security issues, because they use 2.7 for internal projects, not Internet facing.
I am not sure all Linux distributions are ready to ditch completely 2.7 also. Ubuntu is working towards this, but I think they will use version 2.7 for some time after 2020.
About version 3: I am really keen to break all the compatibility prior version 3.7 in each and every new project, because I like it's features very much, but as you say - maybe it is good to write code, compatible with 3.6 and maybe also 3.5...
BTW, congratulations for your project yaml-resume, I will take some time to review it!
Thanks. I was planning to write a post about it when I reach version 1.0 😄
Unfortunately 2.7 is not likely to be dropped soon : some dependencies are not always 3+ compatible, some companies are using homemade software they do not maintain anymore but they can't/don't have time to replace...
Regarding versions prior to 3.7, I think making sur your projects are supporting them is useful because a lot of linux distributions are using rather "old" software. For example, red hat 8 or ubuntu 18.04 both have 3.6 as default python3.
Of course if I need to add a must have feature and it breaks somehow 3.5 support, I'll probably do it 😉
About reaching version 1.0 for your project: Consider posting and discussing prior reaching maturity. This is my personal opinion though, you don't need to follow it... but maybe the community will give you more ideas for your project and you could incorporate better ideas in your version 1.0 :)
My thoughts about Python backward compatibility are - maybe we need to bother with 3.5 and 3.6 backward compatibility only for our public projects - because we do not know which version our users are forced to use... For new live projects, used only by your employer, where you control the environment - I am still convinced we should start with 3.7 and break all backward compatibility...
Yes, Maxime, absolutely valid points.
What I am observing - and I am not commenting if this is right behavior or not - is that many companies still have not refactored their 2.7 project to 3.xx! But they have had many years to plan this?!? Maybe they do not care much of the potential security issues, because they use 2.7 for internal projects, not Internet facing.
I am not sure all Linux distributions are ready to ditch completely 2.7 also. Ubuntu is working towards this, but I think they will use version 2.7 for some time after 2020.
About version 3: I am really keen to break all the compatibility prior version 3.7 in each and every new project, because I like it's features very much, but as you say - maybe it is good to write code, compatible with 3.6 and maybe also 3.5...
BTW, congratulations for your project yaml-resume, I will take some time to review it!
Thanks. I was planning to write a post about it when I reach version 1.0 😄
Unfortunately 2.7 is not likely to be dropped soon : some dependencies are not always 3+ compatible, some companies are using homemade software they do not maintain anymore but they can't/don't have time to replace...
Regarding versions prior to 3.7, I think making sur your projects are supporting them is useful because a lot of linux distributions are using rather "old" software. For example, red hat 8 or ubuntu 18.04 both have 3.6 as default python3.
Of course if I need to add a must have feature and it breaks somehow 3.5 support, I'll probably do it 😉
About reaching version 1.0 for your project: Consider posting and discussing prior reaching maturity. This is my personal opinion though, you don't need to follow it... but maybe the community will give you more ideas for your project and you could incorporate better ideas in your version 1.0 :)
My thoughts about Python backward compatibility are - maybe we need to bother with 3.5 and 3.6 backward compatibility only for our public projects - because we do not know which version our users are forced to use... For new live projects, used only by your employer, where you control the environment - I am still convinced we should start with 3.7 and break all backward compatibility...
Totally agree with the last point.
I might make the article before release then. Just want to have something more than just an idea before.
Really? Are there actually some libraries that aren't 3.x compatible? Can you give some examples?
I was mostly referring to "homemade libraries" you could find inside a company.
But yes, there are some libraries that aren't 3.x compatible. Check on pypi, you will find that a lot of these have very recent releases.
You even have some awesome and very active projects that have restrictions or offers "experimental support" of Python 3 : for example Click or Jinja2.
Ah, that makes sense.