[oslo][release] oslo.limit mistakenly released as 1.0.0

Sean McGinnis sean.mcginnis at gmx.com
Mon Feb 17 19:05:46 UTC 2020

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

More information about the openstack-discuss mailing list