All examples of semantic versioning I've seen show 3 components in use. No more than 2 period characters. At $DAYJOB
, we use 4 components in our release numbers:
5.0.1.2
Does Semantic Versioning allow for this?
And as a higher-level and more arguable side question, does it really even matter? I started to think it might be a good idea to enforce semantic versioning, but ultimately entities like PCI override it.
I should have clarified on my PCI comment. The issue is that audits and their cost influence when the major and minor components change, not necessarily a true new feature. For example, if a feature related to payments is introduced, we bump the minor number for PCI. But if we add a brand new feature related to something in the gui, it doesn't. Only the patch changes. So in this case we don't really get a say in the matter as developers since someone else makes those decisions.
Best Answer
It sounds like you are bypassing normal conventions just to avoid process overhead/audits. That... strikes me as concerning.
What you are doing is effectively making an extra version number (your minor PCI digit) somewhat intentionally in order to move your feature/minor version numbers back a place, to no longer trigger your internal audit criteria.
Anyways, getting to your question about semantic versioning, the spec for Semantic Versioning states:
Emphasis mine.
So the question is, are you using the fourth character for pre-release/build metadata? Or is it basically another version indication that you are releasing?
If "yes" then semantic versioning's spec does allow for it. If "no" then you technically are not following semantic versioning.
Whether you want to rigidly follow it or not is a decision you and your team have to make. The purpose of semantic versioning is to help with API compatibility:
It's a system that helps make it more clear when versioning affects downstream users of the API.
As long as your API is similarly clear it's not a huge deal which way you choose. Semantic versioning just happens to be straightforward, for example if I'm using 3.4.2 and need to upgrade to 3.4.10 I know I can do so without breaking anything. If the new version is 3.5.1 I know it's backwards compatible. And I know version 4.0.1 would be a breaking change.
That's all part of what the version numbers mean.
Ok, this is fine. You have a system which works for you and meets your needs. That's the point of versioning.
If your API is private (only internally facing) it really doesn't matter how you version as long as it makes sense to you and everyone using it. Where versioning in a standard format matters is when you have many other consumers of your API that need to know "what does this version mean?"
Having an arbitrary versioning system will confuse people who are used to other systems, such as semantic versioning. But if no-one is really using your versioning system except the people creating it - it doesn't really matter.