William A. Rowe, Jr. wrote:
[...]
The candidate and number are pitched. We have a mantra,
"version numbers are cheap".
Thanks for the clarification.
[...]
There is typically no
allowance in these rules for making version changes that are not
determined by changes and differences between actual code releases.
Yes, and in fact (unless something went HORRIBLY wrong) the never
released version 1.2.3 enjoys versioning compatibility with 1.2.2
and 1.2.4 per the project's policy. It just simply never existed.
True. The only snag here is that our existing policy deliberately
prevents this from happening.
[...]
You can argue the converse; treating each and every release as
equally stable doesn't help the user. Stating 'whoops, 1.2.3 just
wasn't up to par, so we've released 1.2.4 following 1.2.2' gives the
user one reassurance; the bad releases don't make it out the door.
I don't think of the name of a file mentioned in emails as a release,
least of all when it refers to a transient file in someone's home
directory. Similarly, I don't consider an SVN branch to be an actual
release, even if its contents were identical to it. With this mindset
I can only see one potential effect of skipping versions on users --
that of confusion.
That said, if sticking some suffix (such as -rcN) at the end of the
"release candidate" tarball helps dispel even the slightest concern
of mistaking a pre-release tarball for the real thing, I will gladly
support doing so within the stdcxx release policy.
As always, thanks for the feedback!
Martin
