Open Stack

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.