You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an announcement that, in 2019, this project will be dropping support for Python 2.x all the way through Python 3.4. Python 2.7 will be end-of-life on January 1, 2020 and Python 3.4 just reached end-of-life on March 16, 2019.
Because this is a backwards incompatible change Pydora will release a new major version 2.0 that supports only Python 3.5+. We will leave the 1.x series published to PyPi but no additional releases will be made. Consumers that have a hard dependency on the 1.x series and can not migrate will need to update their requirements to select the older version. For example:
pydora>=1.13,<2
Schedule
Semantic versioning has not historically been a standard in Python code-bases and many Python projects have open-ended dependency selectors (e.g. >=1). Because of this, and to avoid breaking existing consumers the Pydora project will provide 4 months of migration time before releasing 2.0 to allow consumers to update their dependency selectors.
IF YOU HAVE A HARD DEPENDENCY ON PYTHON 2 THAT YOU CAN NOT BREAK PLEASE UPDATE YOUR DEPENDENCY SELECTORS NOW!
April 2019 - a 1.x branch will be introduced for historical tracking of the 1.x series and master will become the development branch for the python3 transition
May 2019 - all proposed changes will be available to consumers in the master branch for testing but will not yet be released to PyPi.
June 2019 - the 2.xseries will be pushed to PyPi as pydora-2.0.0. The 1.x series will continue to be published as well but no new releases will be made. At this point all development on the 1.x series will cease and new development will proceed on the 2.x series.
Other backwards incompatible changes
We will also be removing some deprecated legacy APIs in concert with this change. Specifically the following will be removed:
Factory methods on BaseAPIClient - The ClientBuilder API was introduced in 2015 and is the preferred way to construct an APIClient. Constructing APIClient manually is still supported in the public API but consumers will need to adjust their imports.
__init__.py imports - these imports were originally provided for compatibility with an older file structure and will be removed. Consumers relying on building an APIClient directly will need to modify their imports to use the correct packages instead of relying on the high-level imports.
models breakdown - this package will be broken down to files per functional area (e.g. playlist, station, ads) and the top level __init__.py content will be moved to a differently named file. Although models are part of the public API for Pydora, most consumers should not be importing them directly so this should have limited impact. Consumers who are importing models directly will need to adjust their imports.
py2compat - this file will be completely removed and all uses re-written to their python3 versions
If you will be affected by these changes and can not migrate or have other needs related to this migration please comment on this issue before May 2019. Other constructive comments are welcome as well.
The text was updated successfully, but these errors were encountered:
Given that there have been no objections on this migration I've cut the 1.x branch to track any further development to the 1.x series and have pushed the refactorings noted above to master. This is a little ahead of schedule but should give extra time for testing. Please create issues for any bugs if you find them.
The changes on master will be released to PyPi as pydora-2.0 on June 1, 2019
Dropping Python 2.x support
This is an announcement that, in 2019, this project will be dropping support for Python 2.x all the way through Python 3.4. Python 2.7 will be end-of-life on January 1, 2020 and Python 3.4 just reached end-of-life on March 16, 2019.
Because this is a backwards incompatible change Pydora will release a new major version 2.0 that supports only Python 3.5+. We will leave the 1.x series published to PyPi but no additional releases will be made. Consumers that have a hard dependency on the 1.x series and can not migrate will need to update their requirements to select the older version. For example:
Schedule
Semantic versioning has not historically been a standard in Python code-bases and many Python projects have open-ended dependency selectors (e.g.
>=1
). Because of this, and to avoid breaking existing consumers the Pydora project will provide 4 months of migration time before releasing 2.0 to allow consumers to update their dependency selectors.IF YOU HAVE A HARD DEPENDENCY ON PYTHON 2 THAT YOU CAN NOT BREAK PLEASE UPDATE YOUR DEPENDENCY SELECTORS NOW!
1.x
branch will be introduced for historical tracking of the1.x
series andmaster
will become the development branch for the python3 transitionmaster
branch for testing but will not yet be released to PyPi.2.x
series will be pushed to PyPi aspydora-2.0.0
. The1.x
series will continue to be published as well but no new releases will be made. At this point all development on the1.x
series will cease and new development will proceed on the2.x
series.Other backwards incompatible changes
We will also be removing some deprecated legacy APIs in concert with this change. Specifically the following will be removed:
BaseAPIClient
- The ClientBuilder API was introduced in 2015 and is the preferred way to construct anAPIClient
. ConstructingAPIClient
manually is still supported in the public API but consumers will need to adjust their imports.__init__.py
imports - these imports were originally provided for compatibility with an older file structure and will be removed. Consumers relying on building anAPIClient
directly will need to modify their imports to use the correct packages instead of relying on the high-level imports.__init__.py
content will be moved to a differently named file. Although models are part of the public API for Pydora, most consumers should not be importing them directly so this should have limited impact. Consumers who are importing models directly will need to adjust their imports.Request for comments
If you will be affected by these changes and can not migrate or have other needs related to this migration please comment on this issue before May 2019. Other constructive comments are welcome as well.
The text was updated successfully, but these errors were encountered: