Actually, it doesn't seem that the votes have ever been counted here. In view of SymPy willing to follow NEP 29 (cf. https://groups.google.com/g/sage-devel/c/0BPkiiWYrIU/m/c1vlJoMGEwAJ), it seems natural to join this trend and follow NEP 29.
On Tuesday, May 30, 2023 at 10:35:21 AM UTC+1 G. M.-S. wrote: > > My vote is empty, for the following reasons: > —I think the question asked is not clear enough, as per reactions. > —My "dream" is having an easy to install recent version of SageMath for > everybody wishing to do mathematics with it. Currently this is only the > case for macOS and perhaps some flavours of Linux, AFAICT (my experience > with my students and colleagues is not very good, especially under Windows). > > Guillermo > > On Fri, 26 May 2023 at 12:12, Tobias Diez <tobias...@gmail.com> wrote: > >> Dear Sage developers, >> >> the NumPy enhancement proposal 29: "Recommend Python and Numpy version >> support as a community policy standard" (available at >> https://numpy.org/neps/nep-0029-deprecation_policy.html) specifies when >> it's okay to drop support for old Python version. >> >> Namely, a release should support "all minor versions of Python released >> 42 months prior to the project, and at minimum the two latest minor >> versions. ". In particular, this means: >> - Currently, Sage should support > 3.8. >> - On Apr 05, 2024 we should drop support for Python 3.9 (initially >> released on Oct 05, 2020) >> >> Based on previous discussions on this topic ( >> https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/2sTiwdKPBQAJ, >> https://github.com/sagemath/sage/issues/30384, >> https://github.com/sagemath/sage/pull/35403), I'm calling for a vote on >> adapting the Python version support of NEP 29 in Sage. Voting ends at the >> 7th June, AoE. Please use this thread only for sending votes, to make it >> easier to count them afterward; and use the thread >> https://groups.google.com/g/sage-devel/c/j1cwbTU8aOU/m/2sTiwdKPBQAJ for >> discussion. >> >> *Summary *of the points brought forward in the discussions linked above >> 1. The current practice in Sage is to evaluate whether to increase the >> minimum version of Python supported at the beginning of each release cycle. >> With regard to such a practice, the NEP 29 documents remarks "As there is >> no objective threshold to when the minimum version should be dropped, it is >> easy for these version support discussions to devolve into bike shedding >> <https://en.wikipedia.org/wiki/Wikipedia:Avoid_Parkinson%27s_bicycle-shed_effect> >> >> and acrimony." Sadly, an example of this can be found in the current >> discussion of dropping Python 3.8 support in >> https://github.com/sagemath/sage/pull/35404 with emotions running so >> high that sage-abuse had to step in. Adopting a version policy would >> prevent such discussions. On the other hand, by following a given policy, >> we would loose some flexibility. >> 2. The main idea of NEP 29 is to have a community-wide standard. It is >> followed by many scientific packages such as Scipy, Matplotlib, IPython, >> Jupyter, Pandas, scikit, astropy, cuda, cirq, jax, pytorch among others. The >> adoption of NEP 29 will harmonize Sage's deprecation policy with these >> other major libraries. >> 3. The NEP 29 drop schedule is much faster than the EOL schedule of >> Python itself. Python 3.8 is supported until 2024-10, but NEP 29 already >> drops it 2023-04. However, adhering to the EOL schedule would prevent us to >> updating these packages that follow NEP 29. >> 4. The NEP 29 schedule is about one release cycle faster than the >> previous drops (e.g. Python 3.7 support was dropped in Sage 9.7 while >> according to NEP 29 it would have been Sage 9.6). >> 5. The faster drop schedule will free developer resources (less systems >> to test) and potentially increase developer productivity as it allows us to >> use newer language features. >> 6. The faster drop schedule might be inconvenient for users who rely on >> older Python versions. To some extend this is remedied by our python >> install package, and relatively straightforward upgrade paths on most >> system. One should also note that users relying on other scientific python >> packages are likely forced to upgrade anyway, since these other packages >> likely follow NEP 29. >> 7. The faster drop schedule would force users to upgrade to newer Python >> versions and thereby profit from fewer bugs and security issues. It is >> however questionable if Sage should play this educator role. >> 8. One of the main goals of NEP 29 is to improve downstream project >> planning by having a community-wide standard. This is currently not very >> relevant for us as Sage is currently upstream of nothing except for some >> user packages. With the modularization effort, this may change in the >> future. >> 9. There are not many other documented policies. As said above, most >> scientific python projects follow NEP 29. Most projects in web development >> (e.g flask) seem to drop a version once it reaches EOL. Machine learning >> projects follow a similar EOL policy (e.g. tensorflow) or roughly follow >> NEP 29 (scikit-learn). Some end-user applications have even stricter >> version constraints then NEP 29 (e.g. home-assistant only supports the two >> latest minor releases). >> > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/6e8ff50f-694f-49e0-a5a6-d102eadcce4bn%40googlegroups.com.
