python / python/devguide

Add the other dev phase dates to Status of Python versions

Open
#998 2 comments 2 reactions 1 assignee View on GitHub

@CAM-Gerlach is already working on this.

Since Dec 6, 2022.

infra topic-versions type-feature
Dominant language
Python
Stars
2.1k
Forks
1k
Avg merge
2d 12h
Merged PRs (30d)
12

Description

As [discussed] on PR #988 and at the Python Docs Community meeting, the Status of Python versions table is missing an indication of the expected/actual cut-over point between bugfix and security-only releases, which is fairly important information in line with the other dates displayed there. This is standard for most pages like this, and the Wikipedia page has it.

Additionally, it would seem to be quite helpful, especially since this is the CPython developer guide, to also add the dates for the dev cycle start, alpha, beta and rc phases, to make it easier for devs to quickly check the current phase and when the next one starts.

We should, at least, add additional JSON fields with this information. Since unfortunately with Mermaid it doesn't seem possible to add multiple segments to the same line, and it would clutter the main chart and table to add all these dates, I suggest we output these dates to a separate chart and table in a "Development Status" section, leaving the main one at the top. Eventually, it would seem ideal to migrate the main chart and table (or at least a simplified version) to the main Python,org site, since it is focused on user-facing information, while the proposed new section would contain developer-facing information

#999 is a followup, adding the individual point release version dates as JSON and subsidiary tables. These could be added to the chart in the development status section (and perhaps the latest release added to one of the main tables), or possibly the more detailed charts could be added/moved to the per-version subsections.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.