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