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