For the most part, yes. PragVer is conceived as a superset and tries to stay compatible with the spirit of SemVer. On the other hand, the specification tries to be a bit more abstract so that it can be used for other types of artifacts, apart from software APIs.
Not at all. SemVer is a wonderful versioning schema and you may totally use it if you don’t feel the need to have an additional semantic level for your specific artifact from the beginning. You can decide to adhere to PragVer at a later point of time, if you think it would be more useful.
Not exactly. SemVer foresees an initial development phase where “anything may change at any time”. Major version zero (0.y.z) is reserved for this purpose. There are some problem with this approach though:
PragVer doesn’t promote the idea that incompatible changes should be introduced lightly, but it won’t get in the way of the evolution of your artifact either, even if your releases need to be frequently backwards-incompatible.
You should probably already be at version 184.108.40.206 if:
As soon as you realize that you’ve broken the specification, fix the problem and publish a new minor release that corrects the problem and restores backwards compatibility. Even under this circumstance, it is unacceptable to modify the released contents. If it’s appropriate, document the offending release (for example, mark it as deprecated) and inform your users of the problem so that they are aware of the offending version identifier.
That would be considered backwards-compatible, since it does not affect the consumers of the artifact. Determining whether the changes are corrections (or any other type of alterations) depends on whether you updated the dependencies in order to fix incorrect features or to introduce new functionality. Usually additional changes are required for the latter instance, in which case it’s obviously a minor release.
For example, a patch release incorrectly contains major breaking changes.
Use your best judgment. If you have a huge audience that will be drastically impacted by changing the behavior back to what the artifact intended, then it may be best to publish a major release, even though the fix could strictly be considered a patch release.
Deprecating existing functionality is a normal part of the evolution of an artifact. When you deprecate part of the existing features, you should:
No, but use good judgment. A 255 character version string is probably overkill, for example. Also, specific systems may impose their own limits on the size of the string.