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-1523700289,https://api.github.com/repos/pydata/xarray/issues/7765,1523700289,IC_kwDOAMm_X85a0dJB,2443309,2023-04-26T16:20:47Z,2023-04-26T16:20:47Z,MEMBER,@keewis - you are probably the best person for this task. Can you take on updating our `min_deps_check.py` script?,"{""total_count"": 3, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 2, ""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-1521182209,https://api.github.com/repos/pydata/xarray/issues/7765,1521182209,IC_kwDOAMm_X85aq2YB,2443309,2023-04-25T05:43:31Z,2023-04-25T05:43:31Z,MEMBER,"> 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).
This seems like a good action item to come from this. And seems to align with the thrust of #7777.","{""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-1514362199,https://api.github.com/repos/pydata/xarray/issues/7765,1514362199,IC_kwDOAMm_X85aQ1VX,19690642,2023-04-19T08:47:08Z,2023-04-19T08:47:08Z,NONE,"Pandas seems to also look at the policies of its dependencies like Numpy: https://numpy.org/neps/nep-0029-deprecation_policy.html#support-table
See: https://github.com/pandas-dev/pandas/issues/52513","{""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-1514353030,https://api.github.com/repos/pydata/xarray/issues/7765,1514353030,IC_kwDOAMm_X85aQzGG,19690642,2023-04-19T08:40:02Z,2023-04-19T08:40:02Z,NONE,"What about dependencies like pandas? Maybe it could be a good idea to synchronize policies to avoid conflicts there.
As written before, xarray is currently broken when installing it with `pip install xarray` on Python 3.8 (default version on Ubuntu 20.04 (2 years of support still) for example), since Pandas 2 will be installed as a dependency.
I now need to add this to the dependency list of my packages depending on xarray:
```
pandas<2; python_version=='3.8'
```
Maybe this should be documented somewhere. But it is still inconvenient.","{""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-1513752157,https://api.github.com/repos/pydata/xarray/issues/7765,1513752157,IC_kwDOAMm_X85aOgZd,2443309,2023-04-18T20:24:16Z,2023-04-18T20:24:16Z,MEMBER,"@keewis - thanks for the clarifications on the the version policy related to Python 3.8. Very helpful.
> 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).
This is an interesting proposal. Worth considering.","{""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-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