Make it clear semver has matured past a "proposal"

[aaaidan]

The spec uses words like "we propose" a fair bit, which makes it sound as though it is still a speculative RFC. It seems clear to me that semver is widely accepted and widely used in the software industry (and beyond!)

I propose that we re-word some parts of the spec to be less circumspect, and more directive.

[jwdonahue]

It is still a speculative RFC. There's no one governing board out there that gets to decide what the standard is wrt versioning. There isn't even a consensus around best practices. SemVer is one among many that have proven useful. As for "widely adopted" I would agree, to the extent that there are more than a handful of tools that support it properly. But keep in mind that:

• Many of the most popular of those tools, also support other formats and semantics/workflows as well.
• Many, if not most of the SemVer adopters, do not agree with each other how it should be correctly applied.
• Some of the most widely distributed software, as in billions of customers, do not use anything at all like SemVer.

I would also point out there are some actual software industry governing boards that have their own well defined standards.

[aaaidan]

Thanks @jwdonahue, that all makes a lot of sense. Semvar is just one of many possible strategies and there can be no One True Way for versioning. It’s also not “finished” - and may never be!

For those considering semvar as a versioning strategy (or are simply learning about it), some of the spec wording implies it is still at a very early, and very tentative proposal stage. I think it suggests no real-world agreement or adoption, which is no longer true.

I suggest updating the spec’s tone to match semvar’s current maturity. I think this can be done in a way that doesn’t conflict with the points you’ve raised.

[jwdonahue]

You are always welcome to present a PR/RFC. Just keep in mind that the tone of the current document has contributed to its extensive adoption. It's a distillation of common practice in versioning. It doesn't over-constrain the problem, but seems to get it just about right. It is also the inspiration/basis for more formal specifications.

It’s also not “finished” - and may never be!

If you ask the current maintainers, it's essentially done. They all own packaging tools for a variety of development ecosystems. They all have vested interests in maintaining the status-quo. If you are careful about your proposed new wording, they might accept it. You have to be careful to avoid any prescriptive statements that any one of their tools, doesn't currently abide by. They wish to document only that which is common to all of them. So tonal changes might be accepted. They, me and many others, wish to ensure that we always have the freedom to innovate.

The document was originally written by one person, probably to garner consensus among early developers (employees) of GitHub, as well as their customers. Hence, the "I propose" style language in the original document, apparently updated to "we propose" without actually adhering to the original proposal and bumping the version number.

And now that I got this far into this response, I see you do have a PR, so I will go look at that now...