search

effigies / looseversion

A backwards/forwards-compatible fork of distutils.version.LooseVersion
Other
14 stars 1 forks source link

Wanted: Co-maintainer #15

Open effigies opened 1 year ago

effigies commented 1 year ago

I've been alerted by PyPI that this is a "critical project". I don't mean for this to have much (really, any) churn, but some regular things like making sure new versions of Python are tested in CI will need to happen.

It would be good to add someone who is also authorized to update the repository and upload to PyPI. Let me know if you're interested.

HanzCEO commented 1 year ago

Hi @effigies, I'm interested in helping you to maintain this project. And what would you like to expect from a maintainer?

effigies commented 1 year ago

Hi @HanzCEO, thanks for the interest, and good question! I should have written that down in the first post.

For a co-maintainer, I would want to see a history of maintaining at least one longer-lived project on PyPI. Longer-lived means it's seen releases over a couple Python releases, so the maintainer has some experience with Python lifetime support. This is also intended to weed out opportunists. I would want some assurance that someone has a commitment to the Python ecosystem, and isn't likely to abuse downstream projects by adding exploits or mining crypto or something.

As to what I'd expect a maintainer to do:

1) Don't break the tests. They are intended to ensure that things work exactly how people expect. 2) Update the CI when new Python releases become available. If something breaks, figure out why and adapt. 3) Handle reasonable bug reports (there shouldn't be many). 4) Reject feature requests and resist the urge to add features yourself. Be willing to consider an argument that a "feature" is really a bug fix, but don't get carried away. Better to ruin one person's day by saying no than break a bunch of downstream packages. 5) Maintain a changelog and make a release if something changes. Support for new versions of Python shouldn't require it unless there's a change in code needed.

Shouldn't be too hard, just want to make sure that someone is authorized and empowered to do it if I get hit by a bus.

HanzCEO commented 1 year ago

I think I'm not a good fit for this position yet. I haven't had the experience on creating a long living Python project.

Though, thank you for the opportunity @effigies

wimglenn commented 10 months ago

@effigies Can you clarify the relationship between looseversion.LooseVersion and distutils.LooseVersion, which is maintained by PyPA and still vendored with setuptools? Is it expected that the maintainer of looseversion should keep APIs 1:1 with PyPA LooseVersion type, if/when the latter has changes?

effigies commented 10 months ago

My understanding is that there is zero interest in pypa/distutils or setuptools to maintain distutils.version. These classes were deprecated in https://github.com/pypa/distutils/pull/75, and we will not be deprecating them, so there is already that divergence.

In any event, the target compatibility is with distutils.Version, which we will convert with looseversion.LooseVersion(str(v)). To the extent that another implementation that provides a distutils package keeps that working, we will continue interoperating, but we will compare according to the rules of the pre-3.12 distutils.version.Looseversion.

wimglenn commented 10 months ago

Got it. I’m happy to be a Co-maintainer if you want.

effigies commented 2 months ago

8 months later... sent you an invite.