html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/issues/7765#issuecomment-1531336259,https://api.github.com/repos/pydata/xarray/issues/7765,1531336259,IC_kwDOAMm_X85bRlZD,14808389,2023-05-02T11:52:35Z,2023-05-02T11:52:35Z,MEMBER,reopening so I can keep track of the second task: creating and automatically updating the support table,"{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1673579421
https://github.com/pydata/xarray/issues/7765#issuecomment-1523691256,https://api.github.com/repos/pydata/xarray/issues/7765,1523691256,IC_kwDOAMm_X85a0a74,14808389,2023-04-26T16:14:25Z,2023-04-26T16:20:14Z,MEMBER,"In the meeting today we decided to both change the min-versions policy for python to 30 months, and to add a release table (something like the one in NEP29, but automatically created with each newly released version – possibly through a polling action that runs once a week or something so we don't increase the docs build time any more). The reason for the latter is that the policy, while a good policy, is not easy to understand, and its full meaning can only be inferred by reading the `min_versions_policy` script.","{""total_count"": 2, ""+1"": 2, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1673579421
https://github.com/pydata/xarray/issues/7765#issuecomment-1513673945,https://api.github.com/repos/pydata/xarray/issues/7765,1513673945,IC_kwDOAMm_X85aONTZ,14808389,2023-04-18T19:15:21Z,2023-04-18T19:16:36Z,MEMBER,"> Is the policy working as designed
yes, it is: we guarantee support for at least 24 months, and only drop support once there's another version of python that was released more than 24 months ago. For example, python 3.8 was initially released on Oct 14, 2019 and python 3.9 was released on Oct 5, 2020. According to our policy we were able to drop python 3.8 for releases after Oct 5, 2022, since that's when python 3.9 was released 24 months ago.
This works very well for infrequent releases, since it guarantees that we don't accidentally require a very new version immediately after its release. However, these admittedly a bit complicated rules make interpreting the policy a bit more challenging than a simple ""X months from this release"" would for projects with frequent releases. Maybe we should add a (automatically created) support table for the core dependencies to the installation guide to make reasoning about the policy easier?
> Python: 24 months from the last bugfix release (security releases are not considered).
That would make the support window less predictable, since the python devs might consider an additional bugfix release depending on the situation (there's a reason why the release peps say, *emphasis mine*: ""X will receive bugfix updates *approximately* every 2 months for *approximately* 18 months""). Instead, maybe we should extend the support for python versions by about 6 months, to a total of 30 months? That would effectively align us with NEP-29, which is our upper limit anyways since that's what our dependencies follow (even if their releases don't usually happen at exactly that date).
And before anyone claims we're dropping support for a python version just because our policy tells us to: I'm excited about a number of changes to python, like the `dict` union and `removeprefix` / `removesuffix` in 3.9, the union types in 3.10, and the exception groups in 3.11, so really there *is* a compelling reason to upgrade as soon as the policy allows for each release.","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,1673579421