[oslo][release] oslo.limit mistakenly released as 1.0.0
Hi, We seem to have created a bit of a problem with the latest oslo.limit release. In keeping with our general policy of bumping the major version when we release libraries without py2 support, oslo.limit got bumped to 1.0. Unfortunately, being a pre-1.0 library it should have only had the minor version bumped. This puts us in an awkward situation since the library is still under heavy development and we expect the API will change, possibly multiple times, before we're ready to commit to a stable API. We also need the ability to continue doing releases during development so we can test the library with consuming projects. I can think of a few options, although I won't guarantee all of these are even possible: * Unpublish 1.0.0 and do further pre-1.0 development on a feature branch cut from before we released 1.0.0. Once we're ready for "1.0", we merge the feature branch to master and release it as 2.0.0. * Stick a big disclaimer in the 1.0.0 docs that it is still under development and proceed to treat 1.0 the same as we would have treated a pre-1.0 library. Again, when ready for "1.0" we tag it 2.0.0. * Make our breaking changes as needed and just continue bumping the major version every release. This unfortunately makes it hard to communicate via the version when the library is ready for use. :-/ * [some better idea that you suggest :-)] Any input on the best way to handle this is greatly appreciated. Thanks. -Ben
On 2/17/20 12:45 PM, Ben Nemec wrote:
Hi,
We seem to have created a bit of a problem with the latest oslo.limit release. In keeping with our general policy of bumping the major version when we release libraries without py2 support, oslo.limit got bumped to 1.0. Unfortunately, being a pre-1.0 library it should have only had the minor version bumped.
This puts us in an awkward situation since the library is still under heavy development and we expect the API will change, possibly multiple times, before we're ready to commit to a stable API. We also need the ability to continue doing releases during development so we can test the library with consuming projects.
I can think of a few options, although I won't guarantee all of these are even possible:
* Unpublish 1.0.0 and do further pre-1.0 development on a feature branch cut from before we released 1.0.0. Once we're ready for "1.0", we merge the feature branch to master and release it as 2.0.0.
In general, the idea of unpublishing something is a Very Bad Thing. That said, in this situation I think it's worth considering. Publishing something as 1.0 conveys something that will be used by consumers to make assumptions about the state of the library, which in this case would be very misleading. It's not easy to unpublish (nor should it be) but if we can get some infra help, we should be able to take down that library from PyPi and push up a patch to the openstack/releases repo removing the 1.0.0 release. We can then do another release patch to do a 0.2.0 (or whatever the team thinks is appropriate) to re-release the package under a version number that more accurately conveys the status of the library.
* Stick a big disclaimer in the 1.0.0 docs that it is still under development and proceed to treat 1.0 the same as we would have treated a pre-1.0 library. Again, when ready for "1.0" we tag it 2.0.0.
This is certainly an options too. And of course, everyone always reads the docs, so we should be totally safe. ;)
* Make our breaking changes as needed and just continue bumping the major version every release. This unfortunately makes it hard to communicate via the version when the library is ready for use. :-/
Also an option. This does work, and there's no reason we can't have multiple major version bumps over a short period of time. But like you say, communication is an issue here, and with the current release we are communicating something that we probably shouldn't be.
* [some better idea that you suggest :-)]
Any input on the best way to handle this is greatly appreciated. Thanks.
-Ben
On Feb 17, 2020, at 2:05 PM, Sean McGinnis <sean.mcginnis@gmx.com> wrote:
On 2/17/20 12:45 PM, Ben Nemec wrote:
Hi,
We seem to have created a bit of a problem with the latest oslo.limit release. In keeping with our general policy of bumping the major version when we release libraries without py2 support, oslo.limit got bumped to 1.0. Unfortunately, being a pre-1.0 library it should have only had the minor version bumped.
This puts us in an awkward situation since the library is still under heavy development and we expect the API will change, possibly multiple times, before we're ready to commit to a stable API. We also need the ability to continue doing releases during development so we can test the library with consuming projects.
I can think of a few options, although I won't guarantee all of these are even possible:
* Unpublish 1.0.0 and do further pre-1.0 development on a feature branch cut from before we released 1.0.0. Once we're ready for "1.0", we merge the feature branch to master and release it as 2.0.0.
In general, the idea of unpublishing something is a Very Bad Thing.
That said, in this situation I think it's worth considering. Publishing something as 1.0 conveys something that will be used by consumers to make assumptions about the state of the library, which in this case would be very misleading.
It's not easy to unpublish (nor should it be) but if we can get some infra help, we should be able to take down that library from PyPi and push up a patch to the openstack/releases repo removing the 1.0.0 release. We can then do another release patch to do a 0.2.0 (or whatever the team thinks is appropriate) to re-release the package under a version number that more accurately conveys the status of the library.
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.
* Stick a big disclaimer in the 1.0.0 docs that it is still under development and proceed to treat 1.0 the same as we would have treated a pre-1.0 library. Again, when ready for "1.0" we tag it 2.0.0.
This is certainly an options too. And of course, everyone always reads the docs, so we should be totally safe. ;)
* Make our breaking changes as needed and just continue bumping the major version every release. This unfortunately makes it hard to communicate via the version when the library is ready for use. :-/
Also an option. This does work, and there's no reason we can't have multiple major version bumps over a short period of time. But like you say, communication is an issue here, and with the current release we are communicating something that we probably shouldn't be.
When is the next breaking release likely to be?
* [some better idea that you suggest :-)]
Any input on the best way to handle this is greatly appreciated. Thanks.
-Ben
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. -- Jeremy Stanley
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.
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-----
Ben Nemec wrote:
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.
As others suggested, the simplest is probably to remove 1.0.0 from PyPI and releases.o.o, and then wait until the API is stable to push a 2.0.0 tag. That way we don't break anything (the tag stays, we still increment releases, we do not rewrite history, we do not use weird post1 bits) but just limit the diffusion of the confusing 1.0.0 artifact. I'm not sure a feature branch is really needed ? -- Thierry Carrez (ttx)
If removing 1.0.0 is the way we choose to go, people who already have 1.0.0 won't be able to get "newer" 0.x.y versions. We will need an announcement to blacklist 1.0.0. Then, when the time comes to finally make it stable, we can choose to either go 2.0.0 or 1.0.1. We should specifically put in the installation page instructions to blacklist 1.0.0 in requirements files. On Tue, Feb 18, 2020 at 11:24 AM Thierry Carrez <thierry@openstack.org> wrote:
Ben Nemec wrote:
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.
As others suggested, the simplest is probably to remove 1.0.0 from PyPI and releases.o.o, and then wait until the API is stable to push a 2.0.0 tag.
That way we don't break anything (the tag stays, we still increment releases, we do not rewrite history, we do not use weird post1 bits) but just limit the diffusion of the confusing 1.0.0 artifact.
I'm not sure a feature branch is really needed ?
-- Thierry Carrez (ttx)
-- Moisés Guimarães Software Engineer Red Hat <https://www.redhat.com> <https://red.ht/sig>
Moises Guimaraes de Medeiros wrote:
If removing 1.0.0 is the way we choose to go, people who already have 1.0.0 won't be able to get "newer" 0.x.y versions.
Indeed. Do we need to release 0.x.y versions before the API stabilizes, though ? Do we expect anything to use it ? If we really do, then the least confusing might be to keep 1.0.0 and bump major every time you release a breaking change. -- Thierry Carrez (ttx)
Le mar. 18 févr. 2020 à 11:42, Thierry Carrez <thierry@openstack.org> a écrit :
Moises Guimaraes de Medeiros wrote:
If removing 1.0.0 is the way we choose to go, people who already have 1.0.0 won't be able to get "newer" 0.x.y versions.
Indeed. Do we need to release 0.x.y versions before the API stabilizes, though ? Do we expect anything to use it ?
If we really do, then the least confusing might be to keep 1.0.0 and bump major every time you release a breaking change.
Could be a more proper solution.
-- Thierry Carrez (ttx)
-- 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-----
On Tue, 2020-02-18 at 11:40 +0100, Thierry Carrez wrote:
Moises Guimaraes de Medeiros wrote:
If removing 1.0.0 is the way we choose to go, people who already have 1.0.0 won't be able to get "newer" 0.x.y versions.
Indeed. Do we need to release 0.x.y versions before the API stabilizes, though ? Do we expect anything to use it ?
If we really do, then the least confusing might be to keep 1.0.0 and bump major every time you release a breaking change.
Agreed. I don't imageine anyone is using this yet, and so long as we use a future major version to indicate breaking changes, what would it matter even if they were? I think we should just keep 1.0.0 and remember to release 2.0.0 when it's done, personally. Certainly a lot less work. Stephen
On 2/18/20 4:40 AM, Thierry Carrez wrote:
Moises Guimaraes de Medeiros wrote:
If removing 1.0.0 is the way we choose to go, people who already have 1.0.0 won't be able to get "newer" 0.x.y versions.
Indeed. Do we need to release 0.x.y versions before the API stabilizes, though ? Do we expect anything to use it ?
Yes, the Nova team has a PoC change up that uses these early releases. That's how we're iterating on the API. I can't guarantee that we'll need more releases, but I'm also not aware of anyone having said, "yep, it's ready" so I do expect more releases.
If we really do, then the least confusing might be to keep 1.0.0 and bump major every time you release a breaking change.
On Tue, 18 Feb 2020 at 15:55, Ben Nemec <openstack@nemebean.com> wrote:
On 2/18/20 4:40 AM, Thierry Carrez wrote:
Moises Guimaraes de Medeiros wrote:
If removing 1.0.0 is the way we choose to go, people who already have 1.0.0 won't be able to get "newer" 0.x.y versions.
Indeed. Do we need to release 0.x.y versions before the API stabilizes, though ? Do we expect anything to use it ?
Yes, the Nova team has a PoC change up that uses these early releases. That's how we're iterating on the API. I can't guarantee that we'll need more releases, but I'm also not aware of anyone having said, "yep, it's ready" so I do expect more releases.
I certainly don't feel like its ready yet. I am pushing on Nova support for unified limits here (but its very WIP right now): https://review.opendev.org/#/c/615180 I was hoping we would better understand two level limits before cutting v1.0.0: https://review.opendev.org/#/c/695527
If we really do, then the least confusing might be to keep 1.0.0 and bump major every time you release a breaking change.
I am +1 this approach. What we have might work well enough. Thanks, johnthetubaguy
I vote for removing 1.0.0 first (ASAP) and then deciding which will be the next version. The longer the time 1.0.0 is available, the harder it will be to push for a 0.x solution. On Tue, Feb 18, 2020 at 11:48 PM John Garbutt <john@johngarbutt.com> wrote:
On Tue, 18 Feb 2020 at 15:55, Ben Nemec <openstack@nemebean.com> wrote:
On 2/18/20 4:40 AM, Thierry Carrez wrote:
Moises Guimaraes de Medeiros wrote:
If removing 1.0.0 is the way we choose to go, people who already have 1.0.0 won't be able to get "newer" 0.x.y versions.
Indeed. Do we need to release 0.x.y versions before the API stabilizes, though ? Do we expect anything to use it ?
Yes, the Nova team has a PoC change up that uses these early releases. That's how we're iterating on the API. I can't guarantee that we'll need more releases, but I'm also not aware of anyone having said, "yep, it's ready" so I do expect more releases.
I certainly don't feel like its ready yet.
I am pushing on Nova support for unified limits here (but its very WIP right now): https://review.opendev.org/#/c/615180
I was hoping we would better understand two level limits before cutting v1.0.0: https://review.opendev.org/#/c/695527
If we really do, then the least confusing might be to keep 1.0.0 and bump major every time you release a breaking change.
I am +1 this approach. What we have might work well enough.
Thanks, johnthetubaguy
-- Moisés Guimarães Software Engineer Red Hat <https://www.redhat.com> <https://red.ht/sig>
Moises Guimaraes de Medeiros wrote:
I vote for removing 1.0.0 first (ASAP) and then deciding which will be the next version. The longer the time 1.0.0 is available, the harder it will be to push for a 0.x solution.
The long-standing position of the release team[1] is that you can't "remove" a release. It's out there. We can hide it so that it's harder to accidentally consume it, but we should otherwise assume that some people got it. So I'm not a big fan of the plan to release 0.x versions and pretending 1.0.0 never happened, potentially breaking upgrades. From a user perspective I see it as equally disruptive to cranking out major releases at each future API break. Rather than rewrite history for an equally-suboptimal result, personally I would just own our mistake and accept that oslo.limit version numbers convey a level of readiness that might not be already there. That seems easier to communicate out than explaining that the 1.0.0 that you may have picked up at one point in the git repo, the tarballs site, Pypi (or any distro that accidentally picked it up since) is not really a thing and you need to take manual cleanup steps to restore local sanity. [1] heck, we even did a presentation about that rule at EuroPython -- Thierry Carrez (ttx)
+1 here is the link to one of the EuroPython talks: https://youtu.be/5MaDhl01fpc?t=1470 On Wed, Feb 19, 2020 at 12:21 PM Thierry Carrez <thierry@openstack.org> wrote:
Moises Guimaraes de Medeiros wrote:
I vote for removing 1.0.0 first (ASAP) and then deciding which will be the next version. The longer the time 1.0.0 is available, the harder it will be to push for a 0.x solution.
The long-standing position of the release team[1] is that you can't "remove" a release. It's out there. We can hide it so that it's harder to accidentally consume it, but we should otherwise assume that some people got it.
So I'm not a big fan of the plan to release 0.x versions and pretending 1.0.0 never happened, potentially breaking upgrades. From a user perspective I see it as equally disruptive to cranking out major releases at each future API break.
Rather than rewrite history for an equally-suboptimal result, personally I would just own our mistake and accept that oslo.limit version numbers convey a level of readiness that might not be already there.
That seems easier to communicate out than explaining that the 1.0.0 that you may have picked up at one point in the git repo, the tarballs site, Pypi (or any distro that accidentally picked it up since) is not really a thing and you need to take manual cleanup steps to restore local sanity.
[1] heck, we even did a presentation about that rule at EuroPython
-- Thierry Carrez (ttx)
-- Moisés Guimarães Software Engineer Red Hat <https://www.redhat.com> <https://red.ht/sig>
On 2/19/20 5:20 AM, Thierry Carrez wrote:
Moises Guimaraes de Medeiros wrote:
I vote for removing 1.0.0 first (ASAP) and then deciding which will be the next version. The longer the time 1.0.0 is available, the harder it will be to push for a 0.x solution.
The long-standing position of the release team[1] is that you can't "remove" a release. It's out there. We can hide it so that it's harder to accidentally consume it, but we should otherwise assume that some people got it.
So I'm not a big fan of the plan to release 0.x versions and pretending 1.0.0 never happened, potentially breaking upgrades. From a user perspective I see it as equally disruptive to cranking out major releases at each future API break.
Rather than rewrite history for an equally-suboptimal result, personally I would just own our mistake and accept that oslo.limit version numbers convey a level of readiness that might not be already there.
That seems easier to communicate out than explaining that the 1.0.0 that you may have picked up at one point in the git repo, the tarballs site, Pypi (or any distro that accidentally picked it up since) is not really a thing and you need to take manual cleanup steps to restore local sanity.
[1] heck, we even did a presentation about that rule at EuroPython
It seems there's no great answer here. This thread has been great to go over the options though. I think after reading through everything, our best bet is probably to just go with documenting the state of 1.0.0, then plan on bumping the major release version on any breaking changes like normal. We are still conveying something that we don't really want to be by the 1.0 designation, and chances are high that the docs will be missed, but at least we would have somewhere to point to if there are any questions about it. So I guess I'm saying, let's cut our losses, move ahead with this 1.0.0 release, and hopefully the library will get to a more complete state that this is no longer an issue. Sean
On 2020-02-19 08:34:58 -0600 (-0600), Sean McGinnis wrote: [...]
We are still conveying something that we don't really want to be by the 1.0 designation, and chances are high that the docs will be missed, but at least we would have somewhere to point to if there are any questions about it. [...]
To what extent is it likely to see production use before Nova has ironed out its consumption of the library? -- Jeremy Stanley
On 2/19/20 8:52 AM, Jeremy Stanley wrote:
On 2020-02-19 08:34:58 -0600 (-0600), Sean McGinnis wrote: [...]
We are still conveying something that we don't really want to be by the 1.0 designation, and chances are high that the docs will be missed, but at least we would have somewhere to point to if there are any questions about it. [...]
To what extent is it likely to see production use before Nova has ironed out its consumption of the library? I would assume the likelihood to be very low.
On 2/19/20 8:54 AM, Sean McGinnis wrote:
On 2/19/20 8:52 AM, Jeremy Stanley wrote:
On 2020-02-19 08:34:58 -0600 (-0600), Sean McGinnis wrote: [...]
We are still conveying something that we don't really want to be by the 1.0 designation, and chances are high that the docs will be missed, but at least we would have somewhere to point to if there are any questions about it. [...]
To what extent is it likely to see production use before Nova has ironed out its consumption of the library? I would assume the likelihood to be very low.
The Nova folks are driving this work so at this point I wouldn't declare the oslo.limit API stable without their signoff.
On 2020-02-19 09:14:49 -0600 (-0600), Ben Nemec wrote:
On 2/19/20 8:54 AM, Sean McGinnis wrote:
On 2/19/20 8:52 AM, Jeremy Stanley wrote:
On 2020-02-19 08:34:58 -0600 (-0600), Sean McGinnis wrote: [...]
We are still conveying something that we don't really want to be by the 1.0 designation, and chances are high that the docs will be missed, but at least we would have somewhere to point to if there are any questions about it. [...]
To what extent is it likely to see production use before Nova has ironed out its consumption of the library?
I would assume the likelihood to be very low.
The Nova folks are driving this work so at this point I wouldn't declare the oslo.limit API stable without their signoff.
With that, I wouldn't expect any other projects to even try to use it before Nova's officially doing so. It sounds like the projects likely to be confused about the production-ready state of the library could be approximately zero regardless of which solution you choose. -- Jeremy Stanley
On 2/18/20 4:34 AM, Moises Guimaraes de Medeiros wrote:
If removing 1.0.0 is the way we choose to go, people who already have 1.0.0 won't be able to get "newer" 0.x.y versions.
We will need an announcement to blacklist 1.0.0. Then, when the time comes to finally make it stable, we can choose to either go 2.0.0 or 1.0.1.
We should specifically put in the installation page instructions to blacklist 1.0.0 in requirements files.
If we pull it from pypi, do we really need to blacklist it? A regular pip install would only find the 0.x versions after that, right? In general, I'm not that concerned about someone having already installed it at this point. It was just released and the only people who are likely aware of the library are the ones working on it. My main concern is that we've released the library with a version number that implies a certain level of completeness that doesn't actually exist yet. Given the length of time it has taken to get it to this point, the possibility exists that this bad state could persist for six months or more. I'd prefer to nip it in the bud now rather than have somebody find it down the road and waste a bunch of time trying to make an incomplete thing work.
On Tue, Feb 18, 2020 at 11:24 AM Thierry Carrez <thierry@openstack.org <mailto:thierry@openstack.org>> wrote:
Ben Nemec wrote: > > > 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.
As others suggested, the simplest is probably to remove 1.0.0 from PyPI and releases.o.o, and then wait until the API is stable to push a 2.0.0 tag.
That way we don't break anything (the tag stays, we still increment releases, we do not rewrite history, we do not use weird post1 bits) but just limit the diffusion of the confusing 1.0.0 artifact.
I'm not sure a feature branch is really needed ?
-- Thierry Carrez (ttx)
--
Moisés Guimarães
Software Engineer
Red Hat <https://www.redhat.com>
On 2/18/20 4:23 AM, Thierry Carrez wrote:
Ben Nemec wrote:
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.
As others suggested, the simplest is probably to remove 1.0.0 from PyPI and releases.o.o, and then wait until the API is stable to push a 2.0.0 tag.
That way we don't break anything (the tag stays, we still increment releases, we do not rewrite history, we do not use weird post1 bits) but just limit the diffusion of the confusing 1.0.0 artifact.
I'm not sure a feature branch is really needed ?
If we could continue to tag master with 0.x releases then no. I think my feature branch option was in case we couldn't have a 0.1.0 tag that was later than 1.0.0 on the same branch.
participants (9)
-
Ben Nemec
-
Doug Hellmann
-
Herve Beraud
-
Jeremy Stanley
-
John Garbutt
-
Moises Guimaraes de Medeiros
-
Sean McGinnis
-
Stephen Finucane
-
Thierry Carrez