When most of your code base is shared for both platforms, I would avoid the usage of different version numbers, because it will bring a lot more effort for writing a coherent changelog or identifying in which version you introduced which changes. However, there is no need to release a "placeholder" build either, since this could produce unnecessary rebuild efforts for anyone who uses your library as a dependency.

Instead, when a new version only fixes bugs for one platform, simply don't release and deploy the corresponding version to the other platform. The next time you release a new version to both platforms the users who read the change logs might notice you skipped one minor version number for "their" platform, but it should be apparent for them why you did this, when your changelog clearly tells them that all you did was fixing bugs for an OS they don't use.

Of course, when both code bases are completely different, those can be seen as two products from the developers point of view, and you can go with #2, but then you would probably not bother keeping versions synchronous on any level, maintain completely different repositories and changelogs.

When most of your code base is shared for both platforms, I would avoid getting version numbers "out of sync", because it will bring a lot more effort for writing a coherent changelog or identifying in which version you introduced which changes. However, there is no need to release a "placeholder" build either, since this could produce unnecessary rebuild efforts for anyone who uses your library as a dependency.

Let us assume 1.4.42 was the last version released for both platforms. When new version "1.4.43" only fixes bugs for platform A, simply don't release and deploy the corresponding version to the other platform B. The next time you release a new version "1.4.44" to both platforms, users of platform B might notice you skipped version "1.4.43" for them. But this is a no-brainer when you take care that you write into your changelog that changes from 1.4.42 to 1.4.43 were only relevant to platform A.

Of course, when both code bases are completely different, those can be seen as two products from the developers point of view, and you can go with #2, but then you would probably not bother keeping versions synchronous on any level, maintain completely different repositories and changelogs.

When most of your code base is shared for both platforms, I would avoid the usage of different version numbers, because it will bring a lot more effort for writing a coherent changelog or identifying in which version you introduced which changes. However, there is no need to release a "placeholder" build either.

Instead, when a new version only fixes bugs for one platform, simply don't release and deploy the corresponding version to the other platform. The next time you release a new version to both platforms the users who read the change logs might notice you skipped one minor version number for "their" platform, but it should be apparent for them why you did this, when your changelog clearly tells them that all you did was fixing bugs for an OS they don't use.

Of course, when both code bases are completely different, those can be seen as two products from the developers point of view, and you can go with #2, but then you would probably not bother keeping versions synchronous on any level, maintain completely different repositories and changelogs.

When most of your code base is shared for both platforms, I would avoid the usage of different version numbers, because it will bring a lot more effort for writing a coherent changelog or identifying in which version you introduced which changes. However, there is no need to release a "placeholder" build either, since this could produce unnecessary rebuild efforts for anyone who uses your library as a dependency.

Instead, when a new version only fixes bugs for one platform, simply don't release and deploy the corresponding version to the other platform. The next time you release a new version to both platforms the users who read the change logs might notice you skipped one minor version number for "their" platform, but it should be apparent for them why you did this, when your changelog clearly tells them that all you did was fixing bugs for an OS they don't use.

Of course, when both code bases are completely different, those can be seen as two products from the developers point of view, and you can go with #2, but then you would probably not bother keeping versions synchronous on any level, maintain completely different repositories and changelogs.