search

tBuLi / symfit

Symbolic Fitting; fitting as it should be.
http://symfit.readthedocs.org
MIT License
236 stars 19 forks source link

Python 3.9 support #327

Closed Jhsmit closed 3 years ago

Jhsmit commented 3 years ago

Added python 3.9 support to setup config and Travis

Perhaps we should consider dropping python 3.5 and python 3.6 support in a new major release of symfit (See for example NEP29 version support)

pckroon commented 3 years ago

Perhaps we should consider dropping python 3.5 and python 3.6 support in a new major release of symfit (See for example NEP29 version support)

Sounds reasonable to me, but how much work would it be to keep supporting them? I'll discuss this with @tBuLi, to see how he wants to deal with releases and version deprecations.

lesshaste commented 3 years ago

Perhaps we should consider dropping python 3.5 and python 3.6 support in a new major release of symfit (See for example NEP29 version support)

Sounds reasonable to me, but how much work would it be to keep supporting them? I'll discuss this with @tBuLi, to see how he wants to deal with releases and version deprecations.

Dropping support for python 3.6 might cause problems for a lot of people. I notice 3.6's release date was December 23, 2016 . Perhaps have a 5 year rule where support will guarantee not to be dropped?

Alternatively python has a release schedule. In this case 3.6.13 final was released on 2021-02-15 and it seems it will carry on getting updates to the end of the year. It might make sense to give some time after the final updated version? 3.5.10 final was released on September 5, 2020 and there will be no more updates. IMHO it makes sense to drop 3.5 support now.

pckroon commented 3 years ago

Thanks for the input. I've pulled up a few relevant links: https://www.python.org/dev/peps/pep-0478/ (py3.5 release schedule) https://www.python.org/dev/peps/pep-0494/ (py3.6 release schedule) https://numpy.org/neps/nep-0029-deprecation_policy.html (NEP29, mentioned by @Jhsmit )

Py35 is end of life, and I have no issues deprecating it, so I agree with you there

Py36 will be EOLed by the end of this year. If we were to drop support for it now we'd be "ahead of the curve" so to speak. Isn't py36 still the default version for Ubuntu 18.04LTS? I expect quite a few people will still be running that.

Numpy et al will drop Py36 support on 23 June 2021 (42 months after release). I'm not sure this will be an issue for us, since pip will just pull the latest numpy available for you version of python. AFAIK we don't depend on new numpy features. We're more bound by scipy versions due to the addition of new minimizers and such. It would mean we'd have to limit ourselves to the features supported by the newest version of scipy available for the lowest python version we support. Since we're pretty bad with keeping up with scipy so far, I don't think this'll be a major issue, but it may mean we drop support for a python version before it's EOL, and after scipy dropped it.

So let's keep supporting py36 for now, especially since numpy/scipy still support it.

Jhsmit commented 3 years ago

Ok, sounds good. With respect to scipy dropping versions before it's EOL, as pointed out in #325, scipy 1.6 already dropped python 3.7. Since we depend heavily on scipy, this is an incentive to drop python 3.7 such that symfit can remain compatible with newer project. Also, dropping py3.6 support does not mean that py3.6 users have to stop using symfit immediately. The 0.5.3 version with py3.6 support is available forever.

Perhaps we should aim for a version 0.5.4 to be released soon-ish where we try to get in as much bug fixes as possible which will then be the final py3.6 supported version (given frequency of symfit releases at 0.5.5 py3.6 will be EOL anyway)

pckroon commented 3 years ago

With respect to scipy dropping versions before it's EOL, as pointed out in #325, scipy 1.6 already dropped python 3.7. Since we depend heavily on scipy, this is an incentive to drop python 3.7 such that symfit can remain compatible with newer project.

For reference: Scipy 1.4.0 requires Py35+ Scipy 1.5.0 requires Py36+ Scipy 1.6.0 requires Py37+

I'm perfectly ok with sticking to scipy 1.5 for the time being. At least until it bites compatibility with scipy 1.6. What this also means is that we should start pinning/specifying scipy versions in our requirements.

Also, dropping py3.6 support does not mean that py3.6 users have to stop using symfit immediately. The 0.5.3 version with py3.6 support is available forever.

Yes, but actually no. It depends a bit on how you define "support". I take it to mean "if you find a bug we'll try to fix it", and we really don't have the people to support anything but the latest version.

Perhaps we should aim for a version 0.5.4 to be released soon-ish where we try to get in as much bug fixes as possible which will then be the final py3.6 supported version (given frequency of symfit releases at 0.5.5 py3.6 will be EOL anyway)

Yes. The 0.6 release could be on the same day, where we drop py36. But IMHO there should always be a bugfix release right before dropping a version.