or why clients shouldn’t be allowed to choose version codes
More often than you may think I’m asked to set an app’s version number based on marketing choices or client’s arbitrary preferences.
That’s definitely wrong for a bunch of good reasons.
Before trying to say why, let’s hear what I’ve come into some time ago.
I’ve been developing a mobile app for a client but they at first couldn’t get to publish it on the store for legal issues.
Meanwhile they distributed the app outside the official store to their customers.
When they finally got rid of legal issues they decided to change the icon and graphics of the app and to finally publish it on the store.
At that moment they didn’t want me to properly update the version number as I suggested, claiming that the app had nerver been published on the store before. Well I said, you’re the client, but keep in mind there could be issues with that.
And the issues soon came through!
A few days after the app was published the client came to me with a question: Can you tell me why customers who installed the old version of the app (the one distributed outside the store) are not able to update it via the store?
Everyone here will understand that the reason is “actually it isn’t an update, since it has the same version code of the previous one”, thus the only way to allow those people to update the app would be to publish a new version of the app with the same codebase and a new version code.
This short story is to let you notice that version codes should tell where you are in the development history of your software. From the version of an app you should, for instance, be able to guess whether it’s a bugfix or it has introduced new features.
Without properly set version codes you could totally lose your compass on what’s happening, coming into trouble like what I said above or even worse.
So, when you set the version of your software always be careful and remember that, given a major.minor.patch version number, you should increment:
- patch when you make bugfixes
- minor when you introduce new features
- major when you make changes that break backwards-compatibility or completeley change the user experience
That being said, in the daily practice, if you want to start with a development phase before going to production the simplest thing could be to start with a 0.1.0 version number and increment minors at each new development release.
Also keep in mind that if you’re working on a production project it’s always a good idea to start with a 1.0.0 version code.