Are there any standards for versioning software that has multiple platform clients?

I'm pretty clear on most of the standards regarding versioning a piece of software. The whole major.minor.revision/build/whatever scheme. But I'm not very sure whether there are any conventions when the software can be installed on multiple platforms, with each installation having a somewhat independent cycle. For example, I have an app that has the following clients: - Web - Desktop - iPad - Mobile: - iPhone - Android

All the开发者_Python百科se clients might not have the exact same functionality and they don't necessarily launch simultaneously into the world either. Their further release schedules may diverge as well. So, are there any recommendations on how to approach this? Is it just as simple as keeping them all separate? Thus, at any point in time, the suite could look like this: - appname-web 3.1.0 - appname-desktop 2.1.1 - appname-ipad 1.0.0 - appname-iphone 1.5.0 - appname-android 1.6.0

Thanks,

Nick

This is just an example, but it might be illustrative. RedHat packages are built in two stages, first the source code is gathered together into a source package, and then the srpm is built into one binary package per supported archetecture. The name and version are consistent across both the source and all of the different binaries; the version number represents the input. However, the arch is in a different field in the RPM container, and only present on binary packages, since a source package doesn't have anything at all to do with the archetecture. the arch is the output.

Other ways of bundling or tagging packages besides RPM format make this kind of thing more or less explicit; an installer for windows will only supports the one archetecture, windows.

tl;dr: versions and architectures are different things. What clues you give your users about the either depend on your distribution methods, but don't conflate the two.