Use GitHub releases

[lex111]

To discuss versioning and releases. How to use it correctly?

Link: https://help.github.com/articles/creating-releases/

[IzzySoft]

A few items coming to my mind:

• whenever doing a release (e.g. for Playstore), create a new tag
• name the tag v<version> (e.g. v1.2.3 for version 1.2.3) and have the version matching the versionName in your Manifest – that's the most common way it's dealt with here at Github (and one of the requirements for F-Droid inclusion, if you plan that)
• attach the .apk file to the tag, so folks without Playstore can grab it :wink:

[andrewda]

Also create a commit bumping the version number in the package.json (titled something like chore(release): bump version to v1.2.3) and tag that commit as the release.

[IzzySoft]

And do not forget to increase the versionCode with each new release (not Github related, but still important – otherwise Android will not recognize it as new version).

[lex111]

As an example, I like how this is done in mattermost. As @IzzySoft wrote, there are also links to the download of the application for both platforms (it may not be necessary, but I do not like it). But at them it is automated through fastlane (as I correctly understand). Can we also try this tool?

[housseindjirdeh]

Thanks so much folks. I'm going to have to apologize here, with the rush of trying to get platform releases out to the public I should have taken a step back to make sure releases were being applied here.

Thanks so much @IzzySoft - I agree with everything you suggested. I just created our first release to match the version name of the current Android release (v1.1). Unfortunately because iOS was released sooner - the version in the App Store is v1.2. I think I might just bump our next release of both platforms to v1.3 so that they match from then on out (let me know what you folks think).

And I made the mistake of not increasing versionCode when launching a quick Android update so I've experienced that already 😂 Thank you though appreciate the thoughtful tip 🙏 .

@andrewda I like that. The current release I just added has just been tagged with the commit updating package.json.

[housseindjirdeh]

@lex111 I just added the .ipa file thank you 🙌

I actually tried to use fastlane for streamlining the build and archive process from the very beginning and for some reason it never seemed to work as I expected it to. Decided to go with the manual path of running builds and archiving and I'm okay with that at the moment. However definitely open to further exploring fastlane once more to make things simpler.

[lex111]

@housseindjirdeh Definitely, we need to look for ways to automate the process of releases, or make a checklist, how to do it. I also like the idea of keeping a list of changes. It was great if in the release description (or in a separate file CHANGELOG.md?) it was written what was changed. This information probably can be displayed in the version notes (what's new) on Google Play and the App Store.

[IzzySoft]

Thanks for the kind feedback, @housseindjirdeh ! To further encourage you, I've made your app available in my F-Droid repo (while dependencies on proprietary components, here GMS and Firebase, wouldn't permit its inclusion in the official repo, regulations for mine are a little less strict). Updates will be available there within ~24h of your tagging a new release and attaching the .apk here. Hope that's welcome with you :wink:

Oh, and of course it's listed in my corresponding app-listing, right on top where it belongs :grin:

[IzzySoft]

@housseindjirdeh

And I made the mistake of not increasing versionCode when launching a quick Android update so I've experienced that already

Yeah – right now. Please check versionCode and versionName of the latest release :scream: Can you please replace that with the proper .apk file? :wink: What's currently attached as 1.1.0 was what was in my repo as 1.0 (so the repo failed to compile due to duplicates). File seems to be identical, and identifies itself as

package: name='com.gitpoint' versionCode='1' versionName='1.0' platformBuildVersionName='6.0-2704002'

[housseindjirdeh]

Oh I'm sorry, I was sure I uploaded the exact same .apk that went up to the play store. What's the issue exactly? That the repo release represents 1.1.0 and you're seeing versionName of 1.0?

The current apk on the play store is like this. Will make sure to use semantic versioning on the next release but please let me know what's causing the issue for you.

[IzzySoft]

As pointed out: the .apk attached to v1.1.0 shows up with versionCode=1 and versionName=1.0, so it cannot be placed next to the real v1.0 in the repo. Also, if I'd remove the previous version so there's no duplicate, it would still show up as v1.0, not v1.1.0, which would be very confusing for users. And more, if anyone already had v1.0 installed, it would not show up as update.

Thus it'd be much appreciated if you could replace the APK (which even has the same size, to the byte, as the real v1.0) with the correct one. My guess is you just attached the original version again, accidentally.

[IzzySoft]

Ugh, the last release has no APK :scream: Can you please add it to the corresponding tag? Thanks in advance!

[chinesedfan]

@IzzySoft Sorry, 1.7.0 was a mistaken release by @housseindjirdeh. We are not intend to release yet. I have updated the release notes with explanation.

[IzzySoft]

Ah, I see. Thanks for your quick reaction! Maybe you rather wish to remove the tag then?

[chinesedfan]

@IzzySoft Never mind. We will use 1.7.1 or 1.8.0 as the next tag. Technically, removing the tag is easy. But if someone has pulled the tag, he/she needs to remove locally, too.

[IzzySoft]

@chinesedfan OK, was just a suggestion. Looking forward to 1.7.1/1.8.0 then :wink: Thanks again!