On Wed, 14 Dec 2022 at 09:45, Miro Hrončok <mhroncok@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).

How does this sound?

Add a tox4 which conflicts with tox3 and tox. Then release a tox3 which replaces tox and has a prominent END-OF-LIFE file and possibly in the Info that this is the last release of tox3 and it will be removed from EPEL around RHEL-9.2. Then set tox3's shelf-life to 2023-07-01 in pdc. (move dates to what you want). Then it goes and everyone knows why it went.

Is that a sensible approach for EPEL?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave@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.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Stephen Smoogen, Red Hat Automotive

Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren