On Tue, May 30, 2023 at 8:19 PM Matthias Koeppe <matthiaskoe...@gmail.com> wrote: > > On Tuesday, May 30, 2023 at 12:00:53 PM UTC-7 Nils Bruin wrote: > > On Tuesday, 30 May 2023 at 11:13:27 UTC-7 tobia...@gmx.de wrote: > > that we normally drop support for older versions right after this support > window (i.e. also adapt the drop schedule > https://numpy.org/neps/nep-0029-deprecation_policy.html#drop-schedule). I've > formulated an improved formulation for this policy at > https://github.com/sagemath/sage/pull/35403#issuecomment-1566110884 which > should hopefully clarify this point. > > (Dropping support means increasing `python_requires` and removing github > tests for this old version, i.e. similar to > https://github.com/sagemath/sage/pull/35404 which is modeled on the PR > drooping Python 3.7.) > > > Formulated like this it would seem to me we could needlessly reduce the > platforms that sage builds on: this suggests that the "drop Python 3.*" PR > would get merged simply because it's time: in theory we could end up with a > release where the sole commit is the dropping of support (in practice > development is way too active for this). > > > Exactly, which is why I have opposed setting Tobias's PR to positive review. > (Note that Volker's release scripts currently do not take dependencies or > declared milestones into account.)
No, that's not how you opposed the PR. 1st, you wrote "it's too early for 10.0" - and indeed, we were close to the 10.0 release. Then, after 10.0 release, you - rather unexpectedly - kept opposing it, for very vague reasons, which you had very hard time to justify. It all smelled of a dictatorship on your side - "I can block, because, hey, we do everything by consensus in Sage, and I don't like it, hence it won't happen". The reason given by Nils above did not come up. You just keep twisting the truth. > > I would expect that such a PR would only get merged as a dependency of some > other PR (that makes a fix, enhancement, or upgrades some other component). > > > Exactly, this has been our current practice. We create the drop ticket as a > placeholder and then, when upgrades of packages are being considered by the > volunteers who contribute to maintaining the Sage distribution, we use it as > a dependency of those upgrade tickets. Making a good, balanced decision is > then very easy with the facts gathered. This has worked well. > > > -- > 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/54aac5b2-b4a9-49bb-993f-439218565576n%40googlegroups.com. -- 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/CAAWYfq0cgcKWMO0ezb5Pug%3D2zBZBqMbfuyEncxBh-BeyBHvo8A%40mail.gmail.com.
