Dependency support policy

[mfisher87]

Let's adopt a policy for dropping older versions of our dependencies that we can use across projects so our users know what to expect.

I recommend SPEC0 as a starting point: https://scientific-python.org/specs/spec-0000/

This would mean we can drop support for Python 3.11 and earlier. We can modify the policy if that feels too aggressive, it's just a starting point :)

[matth-love]

This looks good to me. I'll read over that SPEC0 and let you know if I have any opinions about it, but it makes sense to me so far.

[matth-love]

ok, since we don't really use many packages by default in fetchez, I think we can meet this by just updating pyproject.yaml to requires-python = ">=3.12". More will need to be done in extensions (globato, tranformez), but it looks like that's all we'd need to do for the moment here...so i'll go ahead and do that.

[mfisher87]

Maybe we should create a new policy in the community compass to reflect this, we could call it "backwards compatibility"? Then it can cover some other related topics like semantic versioning and how we document/announce breaking changes.

[matth-love]

That's a great idea! Especially since I'm working on breaking changes to fetchez right now! Specifically, I'm re-organizing the modules and how they're loaded, which breaks the globato/transformez extensions (also downgrading shapely to an optional dependency)...

[mfisher87]

Nice :) I think a good breaking change policy might be:

• We'll announce clearly at the top of the release notes with some emoji (🚨 ?) when breaking changes are included in the release
• We'll follow semver and do a major version bump (except for projects <1.0.0, which allow breaking changes with minor bumps)
• We'll have a space in our docs for "Migration guides" where we'll tell you what you need to do to adapt to a breaking change.