On 2/19/20 5:20 AM, Thierry Carrez wrote:
Moises Guimaraes de Medeiros wrote:
I vote for removing 1.0.0 first (ASAP) and then deciding which will be the next version. The longer the time 1.0.0 is available, the harder it will be to push for a 0.x solution.
The long-standing position of the release team[1] is that you can't "remove" a release. It's out there. We can hide it so that it's harder to accidentally consume it, but we should otherwise assume that some people got it.
So I'm not a big fan of the plan to release 0.x versions and pretending 1.0.0 never happened, potentially breaking upgrades. From a user perspective I see it as equally disruptive to cranking out major releases at each future API break.
Rather than rewrite history for an equally-suboptimal result, personally I would just own our mistake and accept that oslo.limit version numbers convey a level of readiness that might not be already there.
That seems easier to communicate out than explaining that the 1.0.0 that you may have picked up at one point in the git repo, the tarballs site, Pypi (or any distro that accidentally picked it up since) is not really a thing and you need to take manual cleanup steps to restore local sanity.
[1] heck, we even did a presentation about that rule at EuroPython
It seems there's no great answer here. This thread has been great to go over the options though. I think after reading through everything, our best bet is probably to just go with documenting the state of 1.0.0, then plan on bumping the major release version on any breaking changes like normal. We are still conveying something that we don't really want to be by the 1.0 designation, and chances are high that the docs will be missed, but at least we would have somewhere to point to if there are any questions about it. So I guess I'm saying, let's cut our losses, move ahead with this 1.0.0 release, and hopefully the library will get to a more complete state that this is no longer an issue. Sean