2

What's the semantic version of the same software for different OS ?

For exemple : X.Y.Z X is a major version Y is a minor version Z is a patch

If I have the same version but for 3 different OS; How can I call them ?

I don't find the answer in semver.org or in google..

5
  • 3
    Semantic versioning doesn't have anything to say about the OS a particular piece of software runs on. Change the name of the software to indicate that it is OS-specific. Commented May 12, 2016 at 19:29
  • I don't know if you'd even change the name of the software. I've never seen the OS-name get appended onto the software name... I think it's a matter of just knowing which executable you've downloaded and that it will run on a particular OS... Like if you're on Windows you don't download the package that runs on Linux. Commented May 12, 2016 at 20:32
  • @StevieV: Maybe not for the actual executable, but certainly for installers. SomeSoftwareSetup_Win64.exe Commented May 12, 2016 at 21:04
  • @RobertHarvey The installers are executable, so I guess you were right. So... I guess not for the software "title"? Commented May 12, 2016 at 21:06
  • No, not for the actual executable, just for the installer. If it's an executable from a managed language like Java or C#, you can set some metadata in the executable's manifest indicating what operating system it is built for. Commented May 12, 2016 at 21:15

1 Answer 1

1

Semantic Versioning is about the API. Assuming it's a single build with different compilers, compiler settings, or build-time configurations, all builds would share the same Semantic Version. If the input to the build process is the same set of code and configuration, the output should also have the same identification.

In this case, item 10 from the Semantic Versioning spec applies:

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD.

Since you are running different build configurations to target different operating systems, you can include this as build metadata. The general structure M.m.p+OS would be appropriate. If you wanted to include additional build metadata, such as timestamps or commit hashes, you could also append those as part of the build metadata.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.