Remove python 3.6 support, and add python 3.10.

[RodneyRichardson]

Signed-off-by: Rodney Richardson rodney.richardson@cambridgeconsultants.com

Fixes #204

[RodneyRichardson]

Please review.

I'm not familiar with the Github build process, so I'm not sure why linux_python_3_6 is tagged as Required, and linux_python_3_10 is not.

I think an admin will need to update branch settings: https://github.com/spdx/tools-python/settings/branches

[licquia]

@goneall I don't appear to have access to the branch protection area for this repository. Can you turn off all the required checks for branch protection? I don't believe those have a lot of value, especially since we're likely to need to make frequent changes to the list of required checks.

[pombredanne]

Please keep 3.6 support for now unless you have a good reason not too. This is still supported in several linux distros.

[pombredanne]

Please do not drop Python 3.6 support

[pombredanne]

Can you turn off all the required checks for branch protection? I don't believe those have a lot of value, especially since we're likely to need to make frequent changes to the list of required checks.

Can you elaborate why you don't believe protecting branches from mistakes does not have a lot of value?

[goneall]

@licquia Are there any specific checks of concern? Currently, the following checks are made:

• Pull request
• 1 approval
• Status Checks
  • continuous-integration/appveyor/pr
  • ci/circleci: linux_python_3_9 through ci/circleci: linux_python_3_6

[RodneyRichardson]

@licquia Are there any specific checks of concern? Currently, the following checks are made:

• Status Checks
  • ci/circleci: linux_python_3_9 through ci/circleci: linux_python_3_6

linux_python_3_6 has been removed, linux_python_3_10 has been added.

[RodneyRichardson]

Please do not drop Python 3.6 support

You may need to take your request to circleci (or python).

[licquia]

Right now, those checks are acting as a barrier to accepting code from a contributor. That's fine, as long as:

• it is clear why the contribution is bad
• in cases where the contribution is not bad, there is an easy way to fix it

In this case, we don't have a policy for how long we support old Python releases that I know of, and we don't seem to have a way to remove required tests when the Python version becomes obsolete. I wouldn't have a problem with keeping the requirements if those specific issues are addressed.

@goneall, specifically, I've only got an issue with the per-version tests.

As for Python 3.6: we have been forced to drop testing support on MacOS because it's no longer supported by the upstream testing framework. The release itself is 5.5 years old, and hasn't been supported with security or other patches for about 3.5 years. Do we have a specific reason to continue supporting 3.6? If so, how long will we need to continue that support?

[RodneyRichardson]

I think following the official python support lifecycle would make for a sensible policy. This is a tool used to help manage software inventory, and hence cybersecurity issues. It would seem inconsistent supporting potentially insecure versions of python.

It also makes practical sense if you follow the same policy as your build infrastructure, and circleci seems to follow the python support lifecycle.

[licquia]

@goneall, can we go ahead and remove the requirements for the ci/circleci: linux_python_3 checks?

[goneall]

@pombredanne Thoughts? Seems reasonable to drop 3.6 at this point.

@licquia Before changes, can you create a branch so that those wanting to continue 3.6 can have a branch to work from? Not quite sure what a good name would be - perhaps Python3_6Support?

[licquia]

I'm happy to create such a branch -- if we have someone willing to maintain it, and a plan for how the work in that branch becomes usable for others. Frankly, though, folks using 3.6 are already having to either use old releases or do their own forking and maintenance work, since 3.6 is now unsupported upstream and is getting dropped by the tools and vendors. Do you know of anyone who can take up this work?

[goneall]

I'm happy to create such a branch -- if we have someone willing to maintain it, and a plan for how the work in that branch becomes usable for others.

@licquia based on the previous comments, it sounds like @pombredanne is interested in keeping the 3.6 version available.

IMHO - I don't think we need a commitment in maintaining the branch to create it since this is easy to do now, a bit more difficult to do after several commits (someone would have to research where the incompatibility was introduced to create the branch).

Creating the branch would give anyone interest in maintaining it the option.

I think of it as a nice compromise between dropping support from 3.6 and not taking in any PR's that break 3.6 compatibility.

Let me know if you disagree.

[goneall]

@licquia Since I haven't heard any objections from @pombredanne I removed the linux_python_3_6 requirement. I've also created a tag python3.6 which we can use to create a branch if there is interest. Without at least a tag, it would be very difficult to find the point of divergence for creating a branch for supporting Python 3.6.

[RodneyRichardson]

Is there's anything preventing this being merged? The "changes requested" (i.e. leave in python 3.6) has been addressed by tagging a branch.

[goneall]

@pombredanne I tagged the release - so we can create a 3.6 support branch if needed. OK to merge? Please resolve your comment or add a comment as @RodneyRichardson is looking for this to be merged.

[bjamesv]

@pombredanne also looking for resolution, when you have time, so #221 can be considered for contribution / checks pass.

[RodneyRichardson]

@pombredanne Any chance this can be merged?

[goneall]

@RodneyRichardson - I just pinged @pombredanne as well - if we don't hear back in a week or so, I'll override and merge the PR.

[goneall]

Since we now have a tagged version, we can always create a separate branch which supports Python 3.6 or even revert this PR if the community deems it necessary.

Based on this, I'll go ahead and override the check and merge the PR since it has been outstanding for quite some time.