Open Stack

 ---- On Wed, 06 Jan 2021 10:34:35 -0600 Ben Nemec <openstack at nemebean.com> wrote ----
 > 
 > 
 > On 1/5/21 3:51 PM, Jeremy Stanley wrote:
 > > On 2021-01-05 22:32:58 +0100 (+0100), Pierre Riteau wrote:
 > >> There have been many patches submitted to drop the Python 3.7
 > >> classifier from setup.cfg:
 > >> https://review.opendev.org/q/%2522remove+py37%2522
 > >> The justification is that Wallaby tested runtimes only include 3.6 and 3.8.
 > >>
 > >> Most projects are merging these patches, but I've seen a couple of
 > >> objections from ironic and horizon:
 > >>
 > >> - https://review.opendev.org/c/openstack/python-ironicclient/+/769044
 > >> - https://review.opendev.org/c/openstack/horizon/+/769237
 > >>
 > >> What are the thoughts of the TC and of the overall community on this?
 > >> Should we really drop these classifiers when there are no
 > >> corresponding CI jobs, even though more Python versions may well be
 > >> supported?
 > > 
 > > My recollection of the many discussions we held was that the runtime
 > > document would recommend the default python3 available in our
 > > targeted platforms, but that we would also make a best effort to
 > > test with the latest python3 available to us at the start of the
 > > cycle as well. It was suggested more than once that we should test
 > > all minor versions in between, but this was ruled out based on the
 > > additional CI resources it would consume for minimal gain. Instead
 > > we deemed that testing our target version and the latest available
 > > would give us sufficient confidence that, if those worked, the
 > > versions in between them were likely fine as well. Based on that, I
 > > think the versions projects claim to work with should be contiguous
 > > ranges, not contiguous lists of the exact versions tested (noting
 > > that those aren't particularly *exact* versions to begin with).
 > > 
 > > Apologies for the lack of references to old discussions, I can
 > > probably dig some up from the ML and TC meetings several years back
 > > of folks think it will help inform this further.
 > > 
 > 
 > For what little it's worth, that jives with my hazy memories of the 
 > discussion too. The assumption was that if we tested the upper and lower 
 > bounds of our Python versions then the ones in the middle would be 
 > unlikely to break. It was a compromise to support multiple versions of 
 > Python without spending a ton of testing resources on it.


Exactly, py3.7 is not broken for OpenStack so declaring it not supported is not the right thing.
I remember the discussion when we declared the wallaby (probably from Victoria) testing runtime,
we decided if we test py3.6 and py3.8 it means we are not going to break py3.7 support so indirectly
it is tested and supported. 

And testing runtime does not mean we have to drop everything else testing means projects are all
welcome to keep running the py3.7 testing job on the gate there is no harm in that.

In both cases, either project has an explicit py3.7 job or not we should not remove it from classifiers. 


-gmann

 > 
 >