Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ENH: Propose standard policy for dropping support of old Python versions #14086

Merged
merged 36 commits into from Aug 19, 2019

Conversation

@tacaswell
Copy link
Contributor

@tacaswell tacaswell commented Jul 23, 2019

This NEP is a proposing a standard policy for the community to determine when we age-out support for old versions of Python. This came out of in-person discussions at SciPy earlier in July and scattered discussion across github. This is being proposed by maintainers from Matplotlib, scikit-learn,
IPython, Jupyter, yt, SciPy, NumPy, and scikit-image.

TL;DR:

We propose only supporting versions of Python initially released in the preceding 42 months of a major or minor release of any of our projects.

@tacaswell
Copy link
Contributor Author

@tacaswell tacaswell commented Jul 23, 2019

Loading

@charris charris changed the title Propose standard policy for dropping support Cpython ENH: Propose standard policy for dropping support Cpython Jul 23, 2019
@charris
Copy link
Member

@charris charris commented Jul 23, 2019

RuntimeError: Title for NEP 28 does not start with "NEP 28 — " (note that — here is a special, enlongated dash)

Loading

@charris
Copy link
Member

@charris charris commented Jul 23, 2019

Should send a note to the mailing list. I can do that if you don't want to subscribe.

Loading

doc/neps/nep-0028-deprecation_policy.rst Outdated Show resolved Hide resolved
Loading
@Carreau
Copy link
Contributor

@Carreau Carreau commented Jul 23, 2019

👍 support nep 29 badge.

Loading

release in Dec19 should support py36 and newer, and a project
with a minor release in Nov20 should support py37 and newer.

The current CPython release cadence is 18 months so a 42 month window
Copy link
Contributor

@willingc willingc Jul 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just an FYI. It is highly likely that the release cadence will become shorter than 18 months for CPython.

Loading

Copy link
Contributor Author

@tacaswell tacaswell Jul 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All the more reason for this!

Loading

doc/neps/nep-0028-deprecation_policy.rst Outdated Show resolved Hide resolved
Loading
doc/neps/nep-0028-deprecation_policy.rst Outdated Show resolved Hide resolved
Loading
doc/neps/nep-0028-deprecation_policy.rst Outdated Show resolved Hide resolved
Loading
doc/neps/nep-0028-deprecation_policy.rst Outdated Show resolved Hide resolved
Loading
doc/neps/nep-0028-deprecation_policy.rst Outdated Show resolved Hide resolved
Loading

- support minor versions of ``CPython`` initially released
42 months prior to our planned release date
- always support at least the 2 latest versions of ``CPython``
Copy link
Contributor

@mdhaber mdhaber Jul 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean Project X Version Y will support all minor version of CPython released in the 42 months prior to the release of X vY or the two most recent minor versions of CPython released before X vY, whichever is "greater"?
(I don't mean to suggest this is a clearer way of writing it; just checking understanding.)

Loading

Copy link
Contributor Author

@tacaswell tacaswell Jul 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, as commented below, this is hedging in the case that the Python release cycle slows down significantly (worst case, we don't have a Python minor release for 42 months and the rule says we support no Python ;) ) .

Loading


As the first bug fix release is typically a few months after the
initial release, you can achieve the same name effect by making the
window longer which is easier to explain.
Copy link
Contributor

@mdhaber mdhaber Jul 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is "same name effect" a typo?
"X.Y.1 release" means "first bug fix release"?

You can achieve the same name effect by making the window longer

here, "window" refers to the window relative to the minor release (rather than "window" relative to the first bug fix release),

which is easier to explain.

It is easier to explain a window relative to a minor release than it is to explain a window relative to a first bug fix release?

Maybe the distinction between the two is not so easy to explain : ) I'm afraid I had to read this several times before I understood.

Loading

Copy link
Contributor Author

@tacaswell tacaswell Jul 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried to re-word this, hopefully it is better now?

Loading

doc/neps/nep-0028-deprecation_policy.rst Outdated Show resolved Hide resolved
Loading
Given the current release cadence of the CPython, the proposed time
(42 months) is roughly equivalent to "the last two" CPython minor
versions. However, if CPython changes their release cadence, any rule
based on the number of minor releases will need to be changed.
Copy link
Contributor

@mdhaber mdhaber Jul 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But isn't part of the rule being suggested based on the number of minor releases?

always support at least the 2 latest versions of CPython

By version, do you not mean "minor release" e.g. 3.6 and 3.7?
https://devguide.python.org/devcycle/

Sorry if I'm misunderstanding - but if I do, maybe others would?

Loading

Copy link
Contributor

@Carreau Carreau Jul 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rule is based on time (42 month, 3 and a half year), which happen to be 2 minor version of (C)Python with current release cadence. As pointed by Carol, the release cadence of Python is likely to go up so that would be 3 or minor releases if the new PEP is accepted.

Loading

Copy link
Contributor

@mdhaber mdhaber Jul 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rule is based on time (42 month, 3 and a half year), which happen to be 2 minor version

That's what I thought, as the document is pretty explicit about where the 42 month number comes from. In that case, I would suggest "always support at least the 2 latest versions of CPython" should be dropped from the recommended project development guidelines, as it is redundant. If we want to leave it in there for clarification, maybe it should be explained below the bullets so it does not look like an independent rule.

Loading

Copy link
Contributor Author

@tacaswell tacaswell Jul 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is mostly as a hedge in case anything goes sideways upstream and we don't have a Python release for 42 months. In that case we may have bigger problems.....

Loading

@tacaswell tacaswell changed the title ENH: Propose standard policy for dropping support Cpython ENH: Propose standard policy for dropping support of old Python versions Jul 23, 2019
@tacaswell
Copy link
Contributor Author

@tacaswell tacaswell commented Jul 23, 2019

Thank you everyone for the copy editing, I swear I actually read it before I opened the PR....

Loading

Projects that want to support longer time windows can, but this NEP is
setting a minimum floor for the support window.
@tacaswell
Copy link
Contributor Author

@tacaswell tacaswell commented Aug 14, 2019

On the weekly call we agreed to add language that indicates that these are minimum support windows (42mo / 2 minor versions for python, 24mo / 3 minor versions for numpy). This gives a minimum support window for down-stream projects and institutions to plan against, but lets projects that want to have longer support windows to still use the language but just take their time about actually dropping support.

This NEP is also about signaling to down-down-down stream domain specific packages what sort of support windows they should be having for the grad-student + post-doc projects used by a handful of labs.

NumPy its self will likely go with (42-50mo / 3 python minors minimums), but that is a bit out of scope for this NEP which is meant to be guidance to down stream projects, not policy for NumPy.


On the call we did discuss dropping the minimum Python window to 36 months, but I think the logic for the buffer holds and 3.5 years feels "right" to me (just under an under-grad degree, just over a post-doc, and about half of an (American) PhD). However, it would be very easy to persuade me that it should be lower.

Loading

@mattip
Copy link
Member

@mattip mattip commented Aug 18, 2019

LGTM, I think we can merge this. It has "draft" status, pending further discussion, merging it will make it more discoverable.

Loading

@rgommers
Copy link
Member

@rgommers rgommers commented Aug 19, 2019

LGTM, I think we can merge this. It has "draft" status, pending further discussion, merging it will make it more discoverable.

agreed, merging.

Let's continue the discussion though. After the feedback/concerns (from e.g. @charris, @rth, @GaelVaroquaux) about the 3.5 years being too fast for some packages, the text is changed to a minimum support window. Does that address everyone's concerns?

Loading

@rgommers rgommers merged commit e2b5f60 into numpy:master Aug 19, 2019
16 checks passed
Loading
@tacaswell tacaswell deleted the cpython_support_nep branch Aug 22, 2019
msk pushed a commit to petabi/pkgsrc that referenced this issue Aug 30, 2019
IPython 7.7.0 contain multiple bug fixes and documentation updates; Here are a
few of the outstanding issue fixed:

   - Fix a bug introduced in 7.6 where the ``%matplotlib`` magic would fail on
     previously acceptable arguments
   - Fix the manage location on freebsd
   - Fix error message about aliases after ``%reset`` call in ipykernel
   - Fix Duplication completions in emacs

We are planning to adopt `NEP29 <https://github.com/numpy/numpy/pull/14086>`_
(still currently in draft) which may make this minor version of IPython the
last one to support Python 3.5 and will make the code base more aggressive
toward removing compatibility with older versions of Python.

GitHub now support to give only "Triage" permissions to users; if you'd like to
help close stale issues and labels issues please reach to us with your GitHub
Username and we'll add you to the triage team. It is a great way to start
contributing and a path toward getting commit rights.
@rth
Copy link
Contributor

@rth rth commented Jun 16, 2020

After the feedback/concerns about the 3.5 years being too fast for some packages, the text is changed to a minimum support window. Does that address everyone's concerns?

It might be helpful to revisit this NEP one year later and following discussion in dask/community#66

Starting from next week, it will recommend to drop Python 3.6.

At the same time e.g. at PyPi downloads stats that's still the the most downloaded Python version for numpy,

Screenshot_2020-06-16 PyPI Download Stats
I know that they are not reliable, but still.

If it is dropped, it would also mean dropping PyPy support since Python 3.7 release hasn't been made yet there. It would be nice if the NEP wasn't solely focused on CPython.

Also I find the current formulation of,

This NEP is being put forward by maintainers of Matplotlib, scikit-learn, IPython, Jupyter, yt, SciPy, NumPy, and scikit-image.

a bit misleading. Most of those packages are not actually following the proposed schedule for Python support, but rather use a more conservative support window (which does correspond to a consensus among developers).

If we look at Python 3.5 it could have been dropped in Feb 2019 according to this NEP. Following are the first Python 3.6+ release of the corresponding packages,

  • matplotlib 3.1.0: May 18, 2019 (+2 months)
  • scikit-learn 0.23: May 12, 2020 (+13 months)
  • ipython 7.10: Nov 28, 2019 (+7 months)
  • jupyter:
  • yt: Py3.5 still supported (+16 months)
  • scipy: 1.5.0rc1 May 30, 2020 (+15 months)
  • numpy: 1.19.0rc1 May 18, 2020 (+15 months)
  • scikit-image: 0.17.1 May 8, 2020 (+15 months)

of course there is some added delay due to the 6 to 12 months release frequency, but I imagine most won't similarly drop Python 3.6 in the next 6 month.

So I think it would be helpful add at least 6 month to the proposed window and word the introduction a bit more neutrally, to avoid the situation like https://twitter.com/dask_dev/status/1272928757989249024 where people decide let's drop Python X.X now because numpy, and other core packages will. While they won't for at least another year.

Also with the now yearly CPython release cycle, supporting at least 2 major versions might be quite short.

Loading

@rth
Copy link
Contributor

@rth rth commented Jun 16, 2020

From dask/community#66 (comment) by @Carreau

the NEP was introduced and merged (in october).
So technically it's the first time that we go through a stop of support for a Python version because of this NEP.

Fair enough. I understand it's a bit of a chicken and egg problem. The initiative to specify the minimum supported Numpy and Python versions is certainly necessairy. I'm just saying that if the the core scientific packages in this NEP recommend something, they should follow it, or otherwise re-evaluate the recommendations.

Loading

@Carreau
Copy link
Contributor

@Carreau Carreau commented Jun 16, 2020

Fair enough. I understand it's a bit of a chicken and egg problem. The initiative to specify the minimum supported Numpy and Python versions is certainly necessary. I'm just saying that if the the core scientific packages in this NEP recommend something, they should follow it, or otherwise re-evaluate the recommendations.

But it's the same issue as dropping Python 2.7 as well, the core packages are the one with the most pressure not to drop as they have the most dependees. Recommending something from the core packages is also a strong message to other libraries to stop support so that the core packages can.

Jupyter/IPython is in a good position, we don't have that many dependees, but we are big, so usually can afford aggressive removal support for old versions, but also a bad example (notebook does not test on 3.8, so not sure we are compatible 3.8/3.9/3.10)

Like pep8 says "A foolish consistency is the hobgoblin of little mind", and I don't think NEP 29 should tell developers to make a release on Jun 23 that remove Python 3.6 support, but it a good signal to start the conversation.

Loading

@charris
Copy link
Member

@charris charris commented Jun 16, 2020

We are still testing master against 3.6 and will support 3.9 when it comes out. For wheels on PyPI, my unofficial rule of thumb is < 30 wheels, and since we will likely drop multilinux1 for 1.20, that leaves a fair amount of room. There was good reason to drop 3.5, f-strings were altogether too tempting. If some other compelling Python feature shows up, that too may drive dropping versions in the future. The faster Python release cycle may also drive things at a faster pace.

Loading

@tacaswell
Copy link
Contributor Author

@tacaswell tacaswell commented Jun 16, 2020

The pypi numbers for the core packages are almost certainly dominated by CI runs not actual users (even more so now that pip is getting better about its caching). Because no one (that I am aware of) is planning to pull down old wheels / sdists all of those CI jobs will continue uninterrupted as we start to drop support for old versions of Python on new versions of the libraries.

From the jetbrains survey last fall (https://www.jetbrains.com/lp/python-developers-survey-2019/) ~2/3 of developers are on py37+, that has probably gone up in the last 6 months and will go up more in the next 6-12 months while our projects get through their release cycles. Further, I expect users that are intentionally not upgrading their Python are intentionally not upgrading anything in their environments.

For Matplotlib's side, we are going to get a 3.3 more-or-less now (🤞 for RC1 and branching today), but as soon as we do that I plan to drop py3.6 support on the master branch.

If it is dropped, it would also mean dropping PyPy support since Python 3.7 release hasn't been made yet there. It would be nice if the NEP wasn't solely focused on CPython.

Again, no one is suggesting we pull down old versions, pypy users can continues to use currently released versions of libraries (and bug-fixes of currently released versions) and are no worse off than they are today.

Is there a projected release date for a pypy that support py37? From their latest release announcement they say:

PyPy is a very compliant Python interpreter, almost a drop-in replacement for CPython 2.7, 3.6, and soon 3.7.

so hopefully this concern will sort its self out while our projects go through their release cycles. I think it is consistent with the spirit of NEP29 for a project do decide that they want to also always support at least one version of pypy. However CPython is the more widely used and is the reference implementation so it makes sense to sync the canonical calendar to its releases.

So I think it would be helpful add at least 6 month to the proposed window and word the introduction a bit more neutrally, to avoid the situation like https://twitter.com/dask_dev/status/1272928757989249024 where people decide let's drop Python X.X now because numpy, and other core packages will. While they won't for at least another year.

This seems like the NEP working exactly as it should. We are at the edge of the window so projects should start talking about dropping support for py36.

When this went in there was a long discussion over the suggested period (which started at 36), it is extremely pre-mature to start talking about adjusting it. The recommendation is a floor (so a user can say "if I use python X.Y I can update my libraries for Nmo" and be sure that it will be true), by adjusting the recommendation longer you are saying no project can move faster than that.

I guess I would support adding "if project feel 42 months it too short of a window, we recommend that they adopt a calendar based policy with a longer window, however we discourage projects from adopting shorter windows." to the introduction,but given that this is just a recommendation, I think that is pretty implicit already.

I agree we should do better about matching reality to NEP29, but I think we should do that by actually carrying through on the recommended support windows 😉 .

Loading

@Carreau
Copy link
Contributor

@Carreau Carreau commented Jun 17, 2020

If it is dropped, it would also mean dropping PyPy support since Python 3.7 release hasn't been made yet there. It would be nice if the NEP wasn't solely focused on CPython.

Again, no one is suggesting we pull down old versions, pypy users can continues to use currently released versions of libraries (and bug-fixes of currently released versions) and are no worse off than they are today.

I think this comment was more about the fact that PyPy-master registers as a 3.6 and that PyData projects testing their master against PyPy master branch is a useful feedback For PyPy.

I agree that this is a bit of a strawman arguments as PyPy itself could test against Python 3.6-compatible PyData Project;

Though I'm guessing there might be occasionally requests from the PyPy team to do some changes in downstream project themselves. Which is tough if Project-X-master is not compatible with PyPy-master.

Though if PyPy is really on its way to publish a 3.7-compatible version, then Project-Y-that-has-dropped-36 should have no problem being tested again PyPy-master.

Or Am I misunderstanding ?

Loading

@rth
Copy link
Contributor

@rth rth commented Jun 17, 2020

For PyPy basically the issue that if python_requires is incremented to Py3.7 (as required by this NEP),

  • it won't be possible to run CI on master for projects that would like to test latest stable PyPy (e.g. numpy, scikit-learn). Meaning that changes in the code could break things for PyPy that were working before. Building PyPy 3.7 branch from sources both takes a long time (last time I tried a while ago) and there are still some test failures in the Python test suite as far as I understand.
  • pip installing master will hard error, meaning again harder to contribute PyPy related fixes.
  • pip installing from PyPi will install not the latest version, so one more reason not to adapt PyPy

Delaying to increment python_requires slightly could be a solution dask/community#66 (comment)

Of course we can't wait wait for PyPy release schedule forever, but if it's just a few month it would be worth it. Maybe @mattip could comment more on how he sees this in general.

I think it is consistent with the spirit of NEP29 for a project do decide that they want to also always support at least one version of pypy.

It could be worth explicitly mentioning this alongside other reasons why a project might want to delay dropping Python version support slightly.

I agree that this is a bit of a strawman arguments as PyPy itself could test against Python 3.6-compatible PyData Project;

By the same argument the CPython core team could tests downstream packages to make sure they don't break anything. Difficult to implement for the whole ecosystem. Particularly when testing the development version of packages.

Let's indeed see how the Python 3.6 deprecation goes. The official CPython 3.6 EoL is 2021-12.

Loading

@mattip
Copy link
Member

@mattip mattip commented Jun 17, 2020

PyPy is slowly working towards a python3.7 alpha release, they track the remaining problems in this wiki page based on the current buildbot failures. It is not clear to me how serious any of those failures are. On the one hand we will only find out once we release an alpha, but on the other hand the small PyPy team might be swamped with new issues. I will take up the issue with the PyPy team.

Loading

@shoyer
Copy link
Member

@shoyer shoyer commented Jun 25, 2020

I would like to raise a different proposal for revising NEP 29, specifically to change the formula it uses for calculating when support should be dropped

Proposed revision

  • The general form of the NEP's current support guarantee is: all minor versions of X released in the N months prior to project Y, and at minimum the last M minor versions
    • For distributors of X and projects that use X, this means they only needs to support a minor version of X for N months, unless fewer than M releases are made.
    • For users of Y, this means they always need to stay on at least the Mth most recent version of X. Exactly when they need to upgrade depends on the release cycle of X. There is no minimum time between upgrades.
  • Instead, I would suggest the support guarantee becomes: the minor version of X released at least N months prior to project Y, and all later versions
    • For distributors of X and projects that use X, this means they only need to issue a new release at most every N months. They don't know ahead of time the date on which they can drop support for a given version of X, unless X has regular releases, but they know that if they always issue a new version of their distribution/package every N months users will be OK.
    • For users of Y, this also means they only need to upgrade X at most every N months. They also don't need to know anything about release schedules.

Why do I like this better?

  1. It's simpler. There's only one critical number -- the number of months since a release.

  2. It seems easier, for both distributors and users. They can remember the easy rule "release/upgrade at least once very N months." For example, suppose Ubuntu LTS (every two years) always packages up the latest Python release. Then as long as the Python support window is at least two years (plus the time Ubuntu takes to package up a Python release), users always know they can use the latest Ubuntu LTS.

    In contrast, the current policy also requires users/distributors to know the release schedule for dependencies of packages they use. Depending on the timing of releases, they will have to upgrade somewhat more often than every N months. If the release frequency for a project changes dramatically (which is not uncommon), then minimum number of supported versions of M will likely also need to change.

  3. It generalizes better to other dependencies. In xarray, we adopted a simplified version of this policy for all of our dependencies, setting a different number of months for each dependency and dropping the "last M minor versions" requirement.

    The problem is that outside of (very) large projects like Python and NumPy, most open source projects don't issue releases on a regular cadence. We ended up in a situation where a new release of upstream dependency like h5py could become immediately required by xarray (see pydata/xarray#4179 for details). This is obviously a bit absurd, and also totally our fault, because we dropped the number of versions requirement. But on the other hand, it wasn't obvious why the number of versions mattered until it came up.

    For another concrete example, suppose matplotlib decided to adopt a policy like this for all of its dependencies. One of matplotlib's dependencies is a little project called cycler, which hasn't been released since Feb 2016, around the time when it became a required dependency for matplotlib 2.0. What would happen if suddenly cycler started undergoing rapid development, e.g., if it started issuing a new minor release every few months? The way this policy is written, even a conservative time-window like those suggested in NEP 29 for Python versions would not be appropriate.

    Obviously, judgment could be used to adjust numbers calculated from the current language, but it's nice to have a formula that could be relied upon.

Suggested number of months

For the specific number of prior months that should be supported for Python and NumPy with this new language, I would suggest picking numbers that roughly correspond to the current schedule in NEP 29 (which was based on Python's former 18 month release cycle and NumPy's roughly 6 month release cycle), i.e.,

This project supports:

  • The minor version of Python released at least 24 months prior to the project, and all later versions
  • The minor version of NumPy released at least 18 months prior to the project, and all later versions

With current release schedules, this would mean new Python versions are supported for 3 years from release and new NumPy versions are supported for 2 years from release (but the policy would be robust to future changes).

The specific drop schedule matches up very closely with the existing timelines:

  • Support for Python 3.6 could be dropped on Jun 27, 2020 (24 months after the release of Python 3.7) vs. Jun 23, 2020 currently.
  • Support for NumPy 1.15 could be dropped on Jul 13, 2020 (18 months after the release of NumPy 1.16) vs. Jul 23, 2020 currently.

The number of versions supported would also match up with the current proposal:

  • At least two minor versions of Python would always be supported, unless Python takes more than 24 months between releases
  • At least three minor versions of NumPy would always be supported, unless NumPy takes more than 9 months (on average) between releases

Loading

@stefanv
Copy link
Contributor

@stefanv stefanv commented Jun 25, 2020

Thanks for the proposal, @shoyer. This NEP wasn't written with something like cycler in mind (rather with NumPy and Python that have fairly regular and long release schedules), but I think it would be improved if it offered a general rule, like the one you suggested. Once you do that, the cycler timing example needs to be addressed.

We can perhaps update our calendar script to print out versions of packages that need to be supported, should a library release today. (That script could even take in a requirements.txt file and update it automatically.)

I couldn't think of any corner cases but, then, calendars are tricky :) I'm +1 on updating the NEP as proposed.

Loading

@hugovk
Copy link
Contributor

@hugovk hugovk commented Jun 25, 2020

One thing NEP 29 says:

Given the current release cadence of the Python, the proposed time (42 months) is roughly equivalent to “the last two” Python minor versions. However, if Python changes their release cadence substantially, any rule based solely on the number of minor releases may need to be changed to remain sensible.

Since then, the cadence has changed. PEP 602 says:

This document describes a change in the release calendar for Python starting with Python 3.9. This change accelerates the release cadence such that major versions are released predictably every twelve months, in October every year.

Loading

@Carreau
Copy link
Contributor

@Carreau Carreau commented Jun 25, 2020

the minor version of X released at least N months prior to project Y, and all later versions

So it's both early for me and some structure in english are still weird to me, but the english parser in my head choke on the new phrasing on two things: How to interpret "at least", and also maybe a bit why you added "All later versions".

When I read "at least" I think "python 3.0 was released 12 years ago, that's more than at least 2 years, so I should support it". So basically an unbounded in the past... so I'm confused. I'm sure that's not what you mean and I'm missing a subtlety.

Is the "All later versions" also meant to be unbounded in the future ? Because that also sort of read to me as "all versions of X released after Y", which is really tough as you do not know they might be released.

At least to me the phrasing in the current version is clearer/less ambiguous and I'm not sure I see the difference yet.

I agree @stefanv that this pep was not meant to be generic, but I'm happy to have this update to be a more generic framework. How libraries interprete major/minor is sometime also up to interpretation so the phrasing so the pep guideline should be followed in spirit and likely not to the letter. If we think there might be caveats we can list them in a section at the end that summarize the consideration people should take when adapting this framework.

I'm also +1 to an update to timeline now that Python is on a 1 year cycle. I'm fine if any dates move by a couple of weeks.

Loading

@shoyer
Copy link
Member

@shoyer shoyer commented Jun 25, 2020

the minor version of X released at least N months prior to project Y, and all later versions

So it's both early for me and some structure in english are still weird to me, but the english parser in my head choke on the new phrasing on two things: How to interpret "at least", and also maybe a bit why you added "All later versions".

Is this clearer?

"Project Y supports the latest version of X from N months prior"

In other words, if your project releases today, it should support:

  • The latest version of Python from 24 months ago
  • The latest version of NumPy from 18 months ago.

Here's an implementation as code:

min_supported_version = max(
    version for version, release_date in zip(versions, release_dates)
    if release_date < datetime.utcnow() - relativedelta(months=N)
)

Loading

@stefanv
Copy link
Contributor

@stefanv stefanv commented Jun 26, 2020

@Carreau The "and all since" should be read as all releases from the oldest to the current at time of release---no projecting into the future!

Loading

@Carreau
Copy link
Contributor

@Carreau Carreau commented Jun 29, 2020

As a note today was the last bugfix of 3.7 (last binary release as well), security will be provided until mid-year 2023 as source only. 3.6 also got a source-only security release.

https://blog.python.org/2020/06/python-378-and-3611-now-available-last.html

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet