At first glance the documentation don't seem to quote the version, can you confirm that point. If we decide to drop the pypi version we also need to be sure to keep the documentation version aligned with the latest version available of the doc. If the doc version is only represented by "latest" I don't think that's an issue here. Always in a situation where we decide to drop the pypi version, what's about this doc? (It will become false) => https://releases.openstack.org/ussuri/index.html#ussuri-oslo-limit Could be worth to initiate a doc to track things that should be updated too to don't missing something. Le mar. 18 févr. 2020 à 00:22, Ben Nemec <openstack@nemebean.com> a écrit :
On 2/17/20 2:42 PM, Jeremy Stanley wrote:
On 2020-02-17 15:02:14 -0500 (-0500), Doug Hellmann wrote: [...]
I’m not 100% sure, but I think if you remove a release from PyPI you can’t release again using that version number. So a future stable release would have to be 1.1.0, or something like that. [...]
More accurately, you can't republish the same filename to PyPI even if it's been previously deleted. You could however publish a oslo.limit-1.0.0.post1.tar.gz after deleting oslo.limit-1.0.0.tar.gz though that seems a bit of a messy workaround.
This seems sensible - it would be kind of like rewriting history in a git repo to re-release 1.0 with different content. I'm also completely fine with having to use a different release number for our eventual 1.0 release. It may make our release version checks unhappy, but since this is (hopefully) not a thing we'll be doing regularly I imagine we can find a way around that.
If we can pull the 1.0.0 release that would be ideal since as Sean mentioned people aren't good about reading docs and a 1.0 implies some things that aren't true here.
-- Hervé Beraud Senior Software Engineer Red Hat - Openstack Oslo irc: hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----