Updating tox to 4 in EPEL 9

[Miro Hrončok]

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: [phone]
IRC: mhroncok

[Stephen Smoogen]

On Wed, 14 Dec 2022 at 09:45, Miro Hrončok <mhroncok(a)redhat.com&gt; 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: [phone]
>  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/[e-mail]...
>  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

[Andrew C Aitchison]

On Wed, 14 Dec 2022, Stephen Smoogen wrote:

>  On Wed, 14 Dec 2022 at 09:45, Miro Hrončok
> <mhroncok(a)redhat.com&gt; 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. 
Should tox3 and tox4 *provide* tox ?

-- 
Andrew C. Aitchison                      Kendal, UK
                    andrew(a)aitchison.me.uk

[Maxwell G]

On Wed Dec 14, 2022 at 15:45 +0100, Miro Hrončok 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?
>  
There's no policy against compat packages in EPEL, so I see no problem
with adding a tox4 component. We also have the EPEL Package Retirement
policy[1] that allows you to retire packages as long as you announce it
on the mailing list. BTW, we are currently discussing a slight change to
this policy[2].

It'd be a good idea to decide on a retirement date in advanced for tox 3
and announce it on epel-announce. From there, you'd have to decide
whether to completely retire the tox component and keep tox4 or to
preform an Incompatible Update[3] of the tox package. This would require
approval from the EPEL Steering Committee. Perhaps we can retire tox and
have tox4 Provide tox but not Obsolete it. This way, existing users'
setups won't be updated and potentially broken without explicit action,
but new setups won't get unsupported content. You should open a ticket
on the pagure.io/epel tracker once you have a concrete proposal.

[1]: https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/
[2]: https://pagure.io/epel/pull-request/213
[3]:
https://docs.fedoraproject.org/en-US/epel/epel-policy-incompatible-upgrades/

--
Maxwell G (@gotmax23)
Pronouns: He/Him/His

[Carl George]

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&gt; 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: [phone]
>  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/[e-mail]...
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue


-- 
Carl George

[Miro Hrončok]

On 21. 12. 22 5:44, Carl George wrote:
>  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-upgr... 
I'll take into consideration.

However, as of now we even have some trouble updating tox to 4 in Rawhide so we 
are focusing on that.

-- 
Miro Hrončok
-- 
Phone: [phone]
IRC: mhroncok