<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>We should specifically put in the installation page instructions to blacklist 1.0.0 in requirements files.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 18, 2020 at 11:24 AM Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Ben Nemec wrote:<br>
> <br>
> <br>
> On 2/17/20 2:42 PM, Jeremy Stanley wrote:<br>
>> On 2020-02-17 15:02:14 -0500 (-0500), Doug Hellmann wrote:<br>
>> [...]<br>
>>> I’m not 100% sure, but I think if you remove a release from PyPI<br>
>>> you can’t release again using that version number. So a future<br>
>>> stable release would have to be 1.1.0, or something like that.<br>
>> [...]<br>
>><br>
>> More accurately, you can't republish the same filename to PyPI even<br>
>> if it's been previously deleted. You could however publish a<br>
>> oslo.limit-1.0.0.post1.tar.gz after deleting oslo.limit-1.0.0.tar.gz<br>
>> though that seems a bit of a messy workaround.<br>
>><br>
> <br>
> This seems sensible - it would be kind of like rewriting history in a <br>
> git repo to re-release 1.0 with different content. I'm also completely <br>
> fine with having to use a different release number for our eventual 1.0 <br>
> release. It may make our release version checks unhappy, but since this <br>
> is (hopefully) not a thing we'll be doing regularly I imagine we can <br>
> find a way around that.<br>
> <br>
> If we can pull the 1.0.0 release that would be ideal since as Sean <br>
> mentioned people aren't good about reading docs and a 1.0 implies some <br>
> things that aren't true here.<br>
<br>
As others suggested, the simplest is probably to remove 1.0.0 from PyPI <br>
and releases.o.o, and then wait until the API is stable to push a 2.0.0 tag.<br>
<br>
That way we don't break anything (the tag stays, we still increment <br>
releases, we do not rewrite history, we do not use weird post1 bits) but <br>
just limit the diffusion of the confusing 1.0.0 artifact.<br>
<br>
I'm not sure a feature branch is really needed ?<br>
<br>
-- <br>
Thierry Carrez (ttx)<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>
<p style="font-weight:bold;margin:0px;padding:0px;font-size:14px;text-transform:capitalize;font-family:"RedHatText",sans-serif">
<span>Moisés</span> <span>Guimarães</span><span style="color:rgb(170,170,170);margin:0px"></span>
</p>
<p style="font-weight:normal;font-size:12px;margin:0px;text-transform:capitalize;font-family:"RedHatText",sans-serif">
<span>Software Engineer</span>
</p>
<p style="font-weight:normal;margin:0px 0px 4px;font-size:12px;font-family:"RedHatText",sans-serif">
<a style="color:rgb(0,136,206);font-size:12px;margin:0px;text-decoration:none;font-family:"RedHatText",sans-serif" href="https://www.redhat.com" target="_blank">Red Hat <span></span></a>
</p>
<div style="margin-bottom:4px">
</div>
<p style="font-weight:normal;margin:0px;font-size:12px;font-family:"RedHatText",sans-serif">
</p>
<div style="margin-top:12px">
<table border="0">
<tbody><tr>
<td width="100px"><a href="https://red.ht/sig" target="_blank"> <img src="https://static.redhat.com/libs/redhat/brand-assets/latest/corp/logo.png" width="90" height="auto"></a> </td>
</tr>
</tbody></table>
</div>
</div></div></div></div></div>