scikit-build
Policy for non-upstream releases
When we need to update but upstream has not updated yet, we should have a policy for setting version numbers. The current release with some important fixes from @mayeut is 3.21.1post1, but post releases are not designed for bug fixes, but only metadata changes - if "3.21.1" is already installed, pip will not upgrade it, and if it is already cached, pip will not download the new post release (from what I understand). We could "yank" the non-post release, but I don't know if that helps in the first case (it should fix the second, I think?).
If yanking does fix the "post" problem in both cases, I think that's best. I think only an owner like @jcfr can yank. I think it likely would be better to release "3.21.1.1", where the forth number is the "build" number, if you will, for the Python package, if it does not. We can also assume that' this is a small enough issue and can be fixed by clearing the cache or waiting till the next patch release and not worry about it - the problem is theoretical at the moment, no one had reported an issue.
@henryiii,
thanks for the insight.
I think it likely would be better to release "3.21.1.1", where the forth number is the "build" number
This seems like the right thing to do given your previous explanation. This raises 3 questions:
- shall we do "x.y.z.0" for the first build of CMake "x.y.z" ?
- will it clash with CMake versioning scheme at some point ?
- ~~does versioneer play well with this scheme ?~~ Yes, used on ninja for 1.10.2.1
