5

I'm in the mobile development domain and I use semantic versioning to version my releases. I keep both versions the same as long as new builds are released for both iOS and Android platforms at the same time.

But imagine I fix a bug that appeared only on iOS. Now I have to release a new iOS build so I increase the build number only for the iOS version. Now the versions between the platforms are out of sync.

Do you,

  1. Release a "placeholder" build for Android with the bumped up version just to keep the versions in sync?

  2. Accept the fact that version numbers on separate platforms can and will be different?

How do you handle this case in your work? Or is this a non-issue?

Improve this question
6
  • 1
    Definitely 2. and even in case of common branch will use two different tags for versioning
    – Lazy Badger
    Commented Nov 14, 2022 at 15:38
  • @LazyBadger: if you understood #2 as an approach to let the version numbers get out-of-sync, I think this is bad advice. Not sure if you really meant that, though.
    – Doc Brown
    Commented Nov 15, 2022 at 14:07
  • @DocBrown - we can discuss it, but I think - two versions of the same app with different code- and feature-set (due to bugfix in one) have to have two different ids
    – Lazy Badger
    Commented Nov 15, 2022 at 14:35
  • @LazyBadger: absolutely! But I understand the scenario of the OP that they have one common code base for two platforms, maybe with some platform specific parts. So no "different code-set", but two different apps, maybe with different feature sets available for the end-user (not from the dev's point of view), generated by the build process from the very same code base.
    – Doc Brown
    Commented Nov 15, 2022 at 14:54
  • @DocBrown - I saw your answer to Q just now, thus - I dismiss my opinion, your solution is logically and technically a lot better and easier: mea culpa, I must to think deeper
    – Lazy Badger
    Commented Nov 15, 2022 at 15:20

1 Answer 1

Reset to default
9

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.

Improve this answer
1
  • Thanks for the detailed response. I like this approach. I agree, normal users will hardly notice the skip but for us devs who care about the version, it's less hassle to maintain one rather than two.
    – Isuru
    Commented Nov 15, 2022 at 13:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.