Software release, is it ok to skip version numbers?

Question

So we have a code base that gradle builds into 3 different targets for 3 different clients that are from a business perspective completely separate. To simplify our release workflow, we have opted to keep the same versioning for all targets as less than 5% of changes are client-specific and we'd much rather keep track of one version than 3.

Let's say we make a change in the code base that only affects target A and released it for target A.

We have two options for B and C:

1. Simply skip version, don't talk about it in release notes, it doesn't exist.
   • It doesn't look very nice...
   • I wonder if clients might might perceive this negatively
2. Release version for all three targets:
   • Release notes will have something very generic (that is also a lie): "fixes and improvements"
3. Try to bundle changes so there's always something to talk about in releases
   • For example, if I make a change that is A-specific, I bundle with it a feature or bug fix that is not target-specific so that the release is a legitimate update for all targets.
4. Split the versioning into 3 and keep track of which version in A, B and C correspond to each other
   • Last resort

Any suggestions?

Update: For business reasons, we can't talk about one client with the other clients because from a business perspective, the products are actually different.

Answer 1

It's fine to skip version numbers.

• Java went from version 1.4 directly to 5.
• Angular went from version 2 directly to 4.

Just never go back or do confusing versioning like Microsoft did with Windows (3.1, 95, 98, 2000, ME, XP, Vista, 7, 8, 10)

To avoid your current problem:

• Never have client specific code. Instead take a feature approach. If client A needs a special feature X and client B needs feature Y, you can mention bug fixes to feature X without having to disclose information about client A to client B.
• If you cannot avoid client specific code, try to externalise it into a external library (DLL/jar). If your client specific code needs fixes or enhancements you can update your library without the potential risk of affecting other clients.

Do not lie to your customers. If they ever experience a problem for code that was meant for another customer, they might find out you lied to them and this can have consequences (even legal ones) for you business.

Answer 2

Why not just be honest about it? Just put a general disclaimer somewhere:

Some release contain only client-specific fixes, so not every release is made to every client.

Answer 3

Customers usually don't care much about release numbers accept for getting the latest, but you do. Therefore it is ok to skip release numbers for the customers who are not affected by the "skipped" release.

For the same reason you could simply change your release number sheme from consecutive numbers to month/year like we have for some linux distros. This would avoid discussions with marketing...