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