ResolveLib 2.0 and unsupported Pythons

[pradyunsg]

This is likely a sane thing to do.

[uranusjr]

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

[uranusjr]

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]

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]

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]

+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.