Open Stack

> On Feb 17, 2020, at 2:05 PM, Sean McGinnis <sean.mcginnis at 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