Proposal of automatic versionname, just with taging it

[hannesa2]

(cherry picked from commit 159b882)

To not differ too much from my fork, I make this proposal, to get rid of manual version change in code.
Simply tag it, and the last used tag will be used as versionName

[davigonz]

I like the getGitCommitCount() approach but it would break our wizard implementation, in which we convert the versionName, e.g. 2.13.1, to versionCode, e.g. 21300100 to know the feature slides the app must show when updating or installing a specific version.

About the getTag() method, it changes the versionName fom 2.13.1 to something like oc-android-2.13.1_oem and since the versionName is "used as the version number shown to users" and I would say it's also what appears in Google Play, oc-android-2.13.1_oem is not a good name to be shown to our users, it works fine as an internal tag but not as a versionName for the app.

What do you think? @abelgardep @jesmrec

[hannesa2]

in which we convert the versionName, e.g. 2.13.1, to versionCode, e.g. 21300100

Is this ready necessary ? Only as an idea, I use this changelog info automatically with https://github.com/hannesa2/ChangeLog
It autogenerate changelog on each tag/CI-build, with collection all tags (with filter option, eg 'release' to filter only to customers)

oc-android-2.13.1_oem

I don't know anything about your politics, but I would remove complete this oc-android-....._oem
Btw, it's easy to add such pre/suffix again.

As bigger idea, because customers don't know anything about this magic numbers 2.13.1, you could to switch too an easy to understand logic:

2019-12-16

[michaelstingl]

As bigger idea, because customers don't know anything about this magic numbers 2.13.1, you could to switch too an easy to understand logic:

We'll try to better follow Semantic Versioning …

[jesmrec]

oc-android-2.13.1_oem is not a good name to be shown to our users, it works fine as an internal tag but not as a versionName for the app.

totally agreed. oc-android-2.13.1_oem is only an internal way to tag a commit, that we followed as standard. Of course, we can re-think for other options like the suggested here, but personally i don't like the idea of settings such string as version identifier for the final users.

To move forward this PR, we'd need to adjust our tagging/versioning policy. I agree with @davigonz that something like oc-android-2.13.1_oem is not suitable to set as version in the markets either. We can unify tags and versions as @hannesa2 suggested, but this is not straightforward. Not only in the current code, so other internal builders (CI) run scripts based in such numbers, so removing or changing them then can carry other problems/adjustments to do

So, @michaelstingl @hosy, it is important o know what does oC expect from versioning:

• What to show in Settings view
• How to tag the release commits

without forgetting that customers can set their own numbering, that must fit with the way to calculate for public users.

[hannesa2]

Btw, I'm fine when you still stay and close this pull request.
This means you keep magic numbers = Semantic Versioning and change version by a new commit here

android/owncloudApp/build.gradle

Lines 107 to 108 in 5c144d3

	versionCode = 21300100
	versionName = "2.13.1"

every time

[davigonz]

Is this ready necessary ? Only as an idea, I use this changelog info automatically with https://github.com/hannesa2/ChangeLog

Not sure how that library could help us to change the wizard implementation. If you think you have a better solution to show/hide the wizard depending on the version (without this method) please send us a PR with your solution and we will review it.

This means you keep magic numbers = Semantic Versioning

Well, we have not re-invented the wheel, it's what most of the Android apps show in Google Play, even with more extensions than major, minor and patch.

change version by a new commit here every time

Do not worry, it's not that much, usually changing two lines once every two months.

Thanks for the proposal and the contribution @hannesa2 , really appreciated but I think we will keep what we have for now