Open Stack

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 at openstack.org 
> <mailto:thierry at 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>
>