Versioning using GIT abbreviated commit ID

[smarek]

Using short form of current commit id and appending it to current, manifest defined, versionName

• Edited reports to say if returning version code or name

> gradle assembleRelease -S
Starting a new Gradle Daemon for this build (subsequent builds will be faster).
Importing with getManifestVersionCode()
Returning version code 36
Importing with getManifestVersionName()
Returning version name 0.1.36-alpha-0747dc5

This closes #147

[smarek]

This also removes need to change VersionName with provided PRs and commits, so that should easy up contribution cycle a bit

[SecUpwN]

This also removes need to change VersionName with provided PRs and commits, so that should easy up contribution cycle a bit

Does it? I always changed that by hand to update our CHANGELOG properly. Does that change now?

[smarek]

Yes, you can refer to short commit ids in CHANGELOG to address that in similar manner imho

[SecUpwN]

Yes, you can refer to short commit ids in CHANGELOG to address that in similar manner imho

Pretty neat change! But wouldn't that mean that I'd have to add a new entry in our CHANGELOG for every merged change in our repository? Sorry for asking so much, I'm just trying to find out how to do it later.

[smarek]

Well every Release should be tagged with appropriate repository version anyway, version prefix (ie. 0.1.36-alpha) doesn't change automatically, it's only the suffix -commitid which changes with repository changes.

This removes the need of step https://github.com/SecUpwN/Android-IMSI-Catcher-Detector/wiki/Development-Status#versioning

Releasing manually versionCode when releasing is still needed. Name of release will be suffixed with commit-id from which it was built, so I'd recommend you to change versionCode, do a merge to master and then proceed with building Release APK

[SecUpwN]

...so I'd recommend you to change versionCode, do a merge to master and then proceed with building Release APK

Ha, that's the way we're already doing it! Let's give it a shot, shall we, @He3556? ;-)

[smarek]

Want me to provide signing with config instructions through Gradle in separate PR for building releases?

[SecUpwN]

Want me to provide signing with config instructions through Gradle in separate PR for building releases?

I have talked to @He3556 about this and both of us agree that this is not necessary since others are not intended to build signed releases, that's our job. Waiting for @He3556 to sign off the merge now. ;-)

[SecUpwN]

@larsgrefer, this work seems to have vanished with #652. Are you able to re-enable it for better tracking?

[larsgrefer]

@SecUpwN It currently depends on where you build, on travis and your local machine is everything okay. On buildozer git ist not installed

[SecUpwN]

On buildozer git ist not installed

Ok, then it seems to be an Issue with Buildozer. Will contact them. Case closed. ;-)