Clarify schedule is guideline #272
Conversation
|
yeah i'm not a native english either, so better phrasing welcome.
…On Mon, Oct 2, 2023 at 15:33 Lars Grüter ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In spec-0000/index.md
<#272 (comment)>
:
> +Below is an auto generated schedule, with recommended date for considering
+stopping support. We suggest that the next release in a given quarter is
The grammar might be off here? How about "..., with recommended dates at
which dropping support should be considered." Not an expert either tough.
—
Reply to this email directly, view it on GitHub
<#272 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACR5T7Q7Q6F47U6TWEFSALX5K7EBAVCNFSM6AAAAAA5PEIMISVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTMNJSG43DIMBQG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Co-authored-by: Jarrod Millman <[email protected]>
|
A more broad comment on the wording we're converging on here: is it really the technicalities of when to drop that is confusing? In my experience the big issue is what people think of when "drop" is brought up. Maybe we want to add a disclaimer that says something to the effect of:
|
There was a problem hiding this comment.
Overall I like the softening as this drop schedule is often misquoted and used to somewhat aggressively demand a drop (which is quite annoying for developer infrastructure or when a lot of the optional dependencies are not yet compatible with the new version).
|
I think that would make things more confusing.
in practice it is removing support. I mean if you don't test on CI it might
as well be broken.
For me in IPython, when I drop, i'll bump flags in ou upgrades, and that
will likely remove conditionals like if version_info < ... , so the package
won't work.
let say it work and you put python_requires>= , then even if supported it
won't install.
I think we can leave "drop" to interpretation.
IMHO what maintainer may not realise is that often dropping from main mean
it will get drop from stable a few month later once there is a new release.
…On Mon, Oct 2, 2023 at 19:41 Madicken Munk ***@***.***> wrote:
A more broad comment on the wording we're converging on here: is it really
the technicalities of when to drop that is confusing? In my experience the
big issue is what people think of when "drop" is brought up. Maybe we want
to add a disclaimer that says something to the effect of:
Disclaimer on this SPEC: Drop here is not meant to convey removing support
for specific versions of upstream packages. Instead, we intend to ease
maintenance burden by providing a schedule where upstream version support
is not guaranteed to be supported. This way maintainers have a specific
window of support they may commit to without adding maintenance burden of
deprecations, etc.
—
Reply to this email directly, view it on GitHub
<#272 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AACR5T4RTRQ232HKSIAXHMDX5L4DJAVCNFSM6AAAAAA5PEIMISVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBTGQ3DMNJUHA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
I agree with @Carreau here. While some parts (maybe even 99.9%) keep working when dropping support, removing from CI but not explicitly changing python_requires tended to lead to more problems and a lot of headaches of sorting out bugreports. I also like to be very explicit with minimum versions for dependencies, even if an older one might work, I bake in the minimum that I test with and don't rely on wildcarded versions either. |
Co-authored-by: Brigitta Sipőcz <[email protected]>
That's definitely not what I was trying to imply that we suggest here. I was trying to make it clear that this SPEC isn't intended to add maintenance burden for lower support versions (in both ways -- by not keeping some lower version supported for all time, but also not that dropping support needs to be some huge deal every quarter)? That was my impression from our conversations. Is there a way to be clearer about this so it isn't interpreted aggressively like we've seen in some cases? |
|
Ahh, ok, sorry, then we're all on the very same page :) |
I think otherwise the spec page seem a bit harsh.