[all][tc] Thoughts on Python 3.7 support

Ben Nemec openstack at nemebean.com
Mon Jan 11 17:09:35 UTC 2021



On 1/6/21 3:23 PM, Pierre Riteau wrote:
> On Wed, 6 Jan 2021 at 18:58, Ghanshyam Mann <gmann at ghanshyammann.com> wrote:
>>
>>   ---- 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
> 
> Thanks everyone for your input. Then should we request that those
> patches dropping the 3.7 classifier are abandoned, or reverted if
> already merged?
> 

That would be my takeaway from this discussion, yes.



More information about the openstack-discuss mailing list