skylib releases

[Tony Aiuto]

We're a little bolloxed up right now.  I know semantic versioning does not officially count for 0.x, but that is weasel words to the users.  There was a lot of justified complaint about the breaking update form 0.8.0 to 0.9.0. I do not want to repeat that. https://github.com/bazelbuild/bazel-skylib/issues/163

The important history

• 0.9.0 was done in July
• on Aug 13, a change needed for federation support went in
• We could cut 0.9.1 from that point (or from Aug 23)
• on Sep. 17, we deleted maprule (breaking change)

I could make a 1.0.0 release to reflect the change. But I do not want the federation to depend on that, because that is going to drag all the rule sets along.

Instead, my plan is

• to fork a branch (0.9.1) off of the state at https://github.com/bazelbuild/bazel-skylib/commit/90ea6feaf33e8ef12fdac9981b2efccc6a25c727
• use that to create a 0.9.1 release
• update the federation to depend on that
• on the head branch bump the version number to 1.0.0
• delete the top level lib.bzl rule since we are breaking things
• do a 1.0.0 release from head

Teams using renovate will not get burned by the 0.9.1. AFAIK, renovate should not auto-update from 0.x to 1.x, so they won't get burned by that either.

[Tony Aiuto]

Oh fooey. It's worse than I thought

https://github.com/bazelbuild/bazel-skylib/commit/d2cf1cc2bcd1e879743faf5216c4887b994705af

on July 22, removed lib.bzl. So the breaking change is really early.

As much as I wanted to do this more forgivingly, it will be less work overall to go right to 1.0.0, update the federation to that and manually fix all the upstream rules if there are conflicts.