ResolveLib 2.0 and unsupported Pythons

sarugaku / resolvelib

Resolve abstract dependencies into concrete ones

ISC License

138 stars 31 forks source link

ResolveLib 2.0 and unsupported Pythons #98

Open pradyunsg opened 2 years ago

pradyunsg commented 2 years ago

This is likely a sane thing to do.

uranusjr commented 2 years ago

Maybe a 1.0 release that’s the first and last stable release for Python 2, and drop everything < 3.7 after that?

uranusjr commented 1 year ago

OK now that 1.0 is out, I’m thinking about the follow strategies:

We’ll release ResolveLib 2.0 that follows CPython’s support timeline, dropping EOL versions continuously. We will also adopt modern syntaxes such as inlined typing.
The 1.x series will be kept supported for the foreseeable future, and with 2.7 support. It will not be actively developed on by maintainers, but anyone interested in backporting any features are free to contribute against the branch, and new 1.x releases will happen for backported features and bug fixes.

Any thoughts on this approach?

pradyunsg commented 1 year ago

I personally am not particularly interested in a "supported" 1.x series as proposed. To use more words, I don't wanna spend my volunteered time subsidising the cost of staying on unsupported versions of Python for organisations that haven't been able to keep up for roughly a decade. I think no one should feel obligated to do so unless there's a reason for it that's relevant to them (eg: enjoy working on legacy software, needed for a job function etc). That doesn't mean I'm opposed to someone else spending their time on it though. :)

The 2.0 part sounds good to me!

uranusjr commented 1 year ago

That’s the “not be actively developed on by maintainers” part. I expect the branch to be mostly dorment, but if someone’s going to send a PR I’ll just merge it and release as long as the tests make sense and CI is green.

pfmoore commented 1 year ago

+1 on this strategy. Explicitly keeping 1.0 "live", but making it clear that it's supported only by community contributions, seems like a reasonable approach. Being explicit in the tracker (a template saying "please provide a demonstration of the issue in 2.0" and a "needs community PR" label) might be useful, but that might be over-engineering it given there's not that many bug reports.