Opened 14 months ago

Last modified 12 days ago

#30384 needs_review enhancement

Adopt the “time window-based” policy for support of Python versions from NEP 29

Reported by: mkoeppe Owned by:
Priority: major Milestone: sage-pending
Component: python3 Keywords:
Cc: slelievre, jhpalmieri, mjo Merged in:
Authors: Tobias Diez Reviewers:
Report Upstream: N/A Work issues:
Branch: public/python3/nep29 (Commits, GitHub, GitLab) Commit: 683a1dd1a5a23a7caa98a5c7cc30fdca3d036228
Dependencies: #30766 Stopgaps:

Status badges

Description (last modified by mkoeppe)

Getting the Python 3.8 support in #27754 merged in 9.2 will allow us to adopt the NEP 29 policy (https://numpy.org/neps/nep-0029-deprecation_policy.html) for the Sage library.

In this case we should indicate our intention to follow this policy in our documentation.

Related discussions:

Change History (23)

comment:1 Changed 14 months ago by mkoeppe

  • Cc mjo added
  • Description modified (diff)

comment:2 Changed 14 months ago by mkoeppe

  • Description modified (diff)

comment:3 Changed 14 months ago by mjo

I'm happy to punt on this. +1 from me.

comment:4 Changed 13 months ago by mkoeppe

  • Milestone changed from sage-9.2 to sage-9.3

comment:5 Changed 11 months ago by gh-tobiasdiez

What is needed to follow NEP 29? I voting on the sage dev mailing list?

comment:6 Changed 11 months ago by mkoeppe

https://wiki.sagemath.org/ReleaseTours/sage-9.2#Support_for_Python_3.6.2C_3.8.2C_and_3.9_added already declares the Sage 9.2 conforms to NEP 29.

I think the only thing missing is to add some sentences to the developer manual.

I don't think we need a vote. In general there seems to be limited interest in discussing release policies.

comment:7 Changed 11 months ago by gh-tobiasdiez

  • Branch set to public/python3/nep29
  • Commit set to 964dd295de9c1284587a1e38cb9093c91485156c
  • Status changed from new to needs_review

Ok, I've added a few sentences. Thus, this should be ready for review now.


New commits:

964dd29Add documentation for following NEP 29

comment:8 Changed 11 months ago by mkoeppe

I don't think that NEP 29 requires us to drop support for certain Python versions; rather, it allows us to do so after the listed dates and still be compliant.

Dropping support for a Python version would need a discussion on sage-devel, I would think. (We probably miscommunicated about this.)

comment:9 Changed 11 months ago by mkoeppe

  • Status changed from needs_review to needs_info

comment:10 Changed 11 months ago by gh-tobiasdiez

NEP 29 is actually quite explicit about that one should drop support after the 42 months, e.g "On Jun 23, 2020 drop support for Python 3.6 (initially released on Dec 23, 2016)". But that's, of course, only a recommendation (like everything in this NEP). It could be sage's policy to support also older python versions, but that's then no longer NEP 29 (in it's strict form). However, one should also keep in mind that supporting old Python versions results in technical debt that might be bigger than the gains from supporting old systems.

Also correct me if I'm wrong, but since sage is also installing its own python version, sage can still be used on older systems, right? It is just that the system python is not used.

Should I initiate a discussion on the mailing list, or do you want to do this?

comment:11 Changed 11 months ago by mkoeppe

I wouldn't like to drop Python 3.6 support in the Sage 9.3 release unless there are more substantial reasons, so I think it's better to have this discussion in the 9.4 cycle

comment:12 Changed 9 months ago by gh-tobiasdiez

  • Milestone changed from sage-9.3 to sage-9.4
  • Status changed from needs_info to needs_review

comment:13 Changed 5 months ago by gh-tobiasdiez

I think this can go in now. Actually dropping Python 3.6 support is done at #30551.

comment:14 Changed 3 months ago by slelievre

Author name please.

comment:15 Changed 2 months ago by mkoeppe

  • Milestone changed from sage-9.4 to sage-9.5

comment:16 Changed 2 months ago by slelievre

  • Authors set to Tobias Diez

comment:17 Changed 13 days ago by gh-DaveWitteMorris

  • Status changed from needs_review to needs_work

I apologize if this is noise, but it appears to me that this ticket has the wrong branch. When I click on the link public/python3/nep29 in the branch field, I see a commit that deletes a huge number of lines from src/doc/en/developer/coding_basics.rst, but I think the branch is supposed to be commit 964dd29 of comment:7, which just adds a few lines about following NEP 29.

comment:18 Changed 13 days ago by git

  • Commit changed from 964dd295de9c1284587a1e38cb9093c91485156c to 391863a83b77b7da67524405186feaab8617104e

Branch pushed to git repo; I updated commit sha1. New commits:

391863aMerge

comment:19 Changed 13 days ago by git

  • Commit changed from 391863a83b77b7da67524405186feaab8617104e to 683a1dd1a5a23a7caa98a5c7cc30fdca3d036228

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

683a1ddAdd documentation for following NEP 29

comment:20 Changed 13 days ago by gh-tobiasdiez

  • Status changed from needs_work to needs_review

Yeah, somehow the branch was corrupted. I've now updated to only include the relevant commit. Ready for review again.

comment:21 Changed 12 days ago by mkoeppe

  • Dependencies changed from #27754 to #30766
  • Milestone changed from sage-9.5 to sage-pending
  • Priority changed from critical to major

Got to get Python 3.10 support going before it makes sense to consider this again

comment:22 follow-up: Changed 12 days ago by gh-tobiasdiez

Why? Maybe its not totally clear from the formulation, but this ticket is about how long sage wants to support old versions of Python. I.e., specify a policy for when support for a certain Python version can be dropped to reduce the burden of maintenance. That we try to support the newest version goes without saying.

comment:23 in reply to: ↑ 22 Changed 12 days ago by mkoeppe

Replying to gh-tobiasdiez:

That we try to support the newest version goes without saying.

It goes without saying, but also without much doing, which is the problem

Note: See TracTickets for help on using tickets.