I would prefer using the incompat process [0] to upgrade epel9's
python-tox to version 4, and introducing a python-tox3 compat package.
We could use the same naming scheme in Fedora if it makes any sense to
keep tox 3 around there for some period of time.
[0]
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/
On Wed, Dec 14, 2022 at 8:45 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
Hello folks.
A new major version of tox was released. The bump form version 3 to version 4
should be flawless to users but breaks all the plugins that have not been
updated to the new API yet.
I would like to avoid the need to maintain tox 3 in EPEL9 for many years after
upstream abandoned it (they have no intention to do maintenance releases for
tox 3.x).
We are currently upgrading to tox 4 in Fedora Rawhide. When the dust settles
I'd like to have the possibility to update it in EPEL too.
One way to do it is to package a new tox4 component in EPEL 9 (and make it
conflict with tox < 4) and keep the old tox around until it breaks (the
breakage might mean it no longer supports a newly added Python version being
added to RHEL 9).
Is that a sensible approach for EPEL?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproj...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Carl George