Add Android/iOS version number configuration

[byCedric]

Detailed description

Right now there is no way to customize a versionCode (Android) or buildNumber (iOS). Android will be increased with 1 and iOS will use the exact version name, just like the normal version. I'd figure some people want to customize this. It should work a bit like the build-in tag/version functionality. The only still-unsolved-thing is the build numbers from Android. There is currently no way of detecting the exact build number (integer).

[byCedric]

I think we might as well also create this feature for the normal manifest.version string.

[jaulz]

@byCedric great plugin - thanks already! Though, I face some issues with the Android versioning since it's not really deterministic since it depends on the predecessor. I found this article which suggest to create the version number based on the different parts:

What do you think about it?

[byCedric]

@jaulz Thanks for the kind words and good feedback, I really appreciate it! I totally agree with you that versions should be "calculatable" at any time, without depending on the history. The approach from maxirosson sounds really sensible to me, and I really want to support it.

Unfortunately, not all the variables used within this approach are available. But I think we can cover it by using other available variables. The major, minor and patch versions are available, that's why we both use Semantic Releases 😉, so no problems there. The api level and screen size/gl formats are a different story I'm afraid.

For the api level I think we can simply replace it with the major expo sdk version. So instead of using API 26 for example, we can use Expo 29. Personally, I think it makes sense because the Expo SDK is a fork of React Native which, in their turn, defines the minimum Android API version. So that means the Expo SDK implicitly defines this missing variable. How do you feel about this?

For the screen size or gl formats it's a bit more complicated I'm afraid. I don't see any useful variables, defined in the Expo Manifest, that can cover this. So I would suggest workaround. If we allow the developer to configure a "template" to use as version code for both Android and iOS, we can cover this. It's actually inspired by Semantic Release tagFormat configuration. When the user defines something like ${expo.major}0${next.major}${next.minor}${next.patch}, he can "hard code" (and later modify) this missing data. This is just an example of course, we can also add extra prepared variables like next.android.version (to contain a 2-char padded major, minor & patch) to make it more readable. What do you think about this, does this cover your use case fully?

Sorry for the spam/big message. I will make some time available tomorrow to get this feature implemented asap.

[jaulz]

@byCedric great, I like it! I just updated the PR and included the Expo version as well. We can keep the screen size gl formats as zero for the time being I assume. The template mechanism would of course allow much more possibilities but I am not sure about the complexity we would introduce. What if the user wants to have a 3-char padded part of the version?

[byCedric]

Yeah, you are right. We can introduce it later as new feature. For now your PR looks really good, thanks for updating the documentation too! So, let's release this as new major release of the package. Tomorrow I will try and get a first draft of the templating part started. If this templating is finished, I will default it on Android to the value you are currently calculating (to ensure a smooth transition, without breaking stuff).

[jaulz]

Nice :) Looking forward for the templates! Let me know if you need help.

[byCedric]

@jaulz Your PR was really good, didn't require any big change and I got excited. So it's live in 2.0.0! Let me know if you encounter any issues. Thanks again ❤️

[byCedric]

Quick update, I started with the template feature. Unfortunately, due to a major outage with NPM which I'm also affected by, I can't finish the first draft today. I hope to have it by Wednesday!

[byCedric]

My apologies for taking longer than expected. But, the first draft is finally here! I'll resolve the final issues and test it before releasing. If everything goes well, I'll release it straight afterward.

[byCedric]

Works like a charm, I'm releasing 2.1.0. Again, @jaulz, thank you so much for your awesome suggestion and effort to get it working! Hope you like the new version, the readme now contains a configuration section to get you started. Let me know if you run into trouble. Cheers!

[byCedric]

Released in 2.1.0

[jaulz]

Yeah, thanks a lot, nice work 😊