Open Stack

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