Hi,

I am the maintainer of the "python-astropy" package, that currently
creates packages for both Python 2 and Python 3. Both packages have a
number of reverse dependencies.

Recently, upstream announced a new version 3.0 of astropy, which
supports Python 3 only, and I think of the best mid-term strategy: The
old version 2.0 is supported upstream for ~2 years, and I want to have a
smooth migration path. I checked the wiki, but could not find good
information about migration.

I thought of a temporary package split: create a new source package
"astropy" that inherits of the current python-astropy package, but only
builds python3-astropy (and the utils + doc, which depend on
python3-astropy), and update this to version 3.0. Then I would remove
these binary packages from the python-astropy package. In parallel, I
would file bugs (severity: important) to remove the reverse dependencies
of the Python 2 packages (many of them are mine, but also may have
reverse dependencies).

As long as there are substantial problems with the removal of the Python
2 support, I then keep the "old" python-astropy package updated. Once
everything is figured out and we decide to finally kick out Python 2
support (from Debian-Astro, or from Debian), I would set the remaining
bugs as RC, and (once they are solved) remove the "python-astropy"
package.

Does this sound reasonable? And how should I do this technically?

Best regards

Ole

Reply via email to