Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move 2.1.0 tag and/or release something > 2.1.0? #74

Open
cjwatson opened this issue Nov 7, 2024 · 1 comment
Open

Move 2.1.0 tag and/or release something > 2.1.0? #74

cjwatson opened this issue Nov 7, 2024 · 1 comment

Comments

@cjwatson
Copy link

cjwatson commented Nov 7, 2024

I realize that the following is arguably not really your problem, but I thought you might be interested in it and maybe there's something you could do.

When debugging something else, I noticed recently that Debian's python3-catalogue package is at version 2.1.0, which you yanked from PyPI in favour of continuing to release 2.0.x versions instead. I'm not exactly sure why you yanked that version, but it looked as though it was maybe just changing your mind about whether you needed to bump the minor version? Debian picked this up because our automation for reporting new upstream versions points to GitHub tags in this case, and so nobody noticed that the tag with the higher version number corresponded to a PyPI version that's been yanked.

I opened Debian bug #1086878 to figure out what to do about this. We should clearly get onto a newer release from you, since they have some fixes we need, but as it stands we'll have to implement some workarounds. Again, I realize distro packages aren't your problem, but if you're willing to help then there are two somewhat independent things that would make things a bit easier at our end, and possibly avoid future problems in other distributions:

  • Would you consider moving the 2.1.0 tag to have some name that we can tell apart from regular version numbers, such as yanked-2.1.0? That would make it much easier to exclude it from our latest-upstream-version-check automation.
  • Would you consider making a release with a version higher than 2.1.0? Of course it depends why you yanked 2.1.0, but if it was just because it didn't strictly meet semver minor version bump criteria, maybe an artificial minor bump wouldn't be a big problem. That would mean we wouldn't have to perform fake version shenanigans on our end ("2.1.0+really2.0.10" or similar) to upgrade to the actual latest version.

Thanks in advance!

@cjwatson
Copy link
Author

I eventually found explosion/thinc#408 and #46 which I guess are related to the reasons this was yanked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant