Use Git branches/tags for versioning

[ghost]

Description

MA-2314

The version name (and version code) will now be determined automatically by using, in this order:

• the version number in the BRANCH environment variable (for Travis CI)
• the version number in the git branch name
• the version number reported by git describe

For a branch / tag to be considered, it must start with rc/ or release/ prefix. E.g. rc/2.5.0 or release/2.6.

The version code will be based on the semantic version, allowing 3 digits between each decimal. For example, the version 2.3.67 will result in a version code of 2003067.

To quickly see what version would be used if you were to build right now, you can use the new gradle version task, for example: BRANCH=rc/2.3.0 ./gradlew --quiet version which will print 2.3.0 (2003000)

Travis CI

Travis does not expose the branch or fetch tags by default, so I updated the script to expose a BRANCH as an environment variable, as well as fetch the tags, so that both branch / tag based versioning will work on Travis as well.

Reviewers

If you've been tagged for review, please check your corresponding box once you've given the 👍.

• Code review: @BenjiLee
• Code review: @mdinino

[codecov-io]

@@             master       #774   diff @@
==========================================
  Files           485        485          
  Lines         20599      20599          
  Methods           0          0          
  Messages          0          0          
  Branches       2912       2912          
==========================================
  Hits           3650       3650          
  Misses        16542      16542          
  Partials        407        407          

Review #774 on Codecov

Powered by Codecov. Last updated by 00a1787...132f486

[BenjiLee]

Test failure :(

[BenjiLee]

Can we bump down the versionCode and versionName in master for this PR?

[mdinino]

I'm curios about @BenjiLee 's question too. But other than that 👍

[BenjiLee]

Ah, nvm about bumping the versionCode/Name. I see the change now.

[BenjiLee]

Tried to created a build with a branch called rc/3.4.666, no version displayed

Looks like ./gradlew version is working. It reports back 3.4.666 (3004666)

[BenjiLee]

Additionally, Fabric is reporting the build as 0.0 (0)

[ghost]

@BenjiLee Fixed your issue; strange that it still built fine.

Also fixed Travis

[mdinino]

@brianguertin @BenjiLee

I am wondering how this solution is going to work with what we talked about yesterday. If we have nightly builds. Are they all going to be on an RC branch? Should it be a part of the build automation process to create a new RC branch every time we run the script?

I am wondering if another option of implementing this JIRA ticket is to derive the int number from the timestamp.

[BenjiLee]

We can always create a different trigger for nightly builds. For example, if there is a branch called nightly/2.5.1 it can kick off the build.

[BenjiLee]

We could derive the int from the timestamp. Is there a specific reason to use timestamps?

[mdinino]

No, the only reason I suggested timestamps is that it's unique and always increasing.

My thought was that we modify the Gradle script to convert the time stamp to a int number automatically. Gradle could also take a version int parameter that would override this.

@bguertin What are your thoughts? I don't mind implementing, BTW.

[ghost]

The version int is only important for Google Play distribution, our testing builds have no reason to depend on it's value or to increment it. I think it is in our best interest to forget it exists, and rely only on the semantic version.

Like Chris said, we could easily customize the nightly build (or any build) to use a particular version if we need to. If building off master right now, it will use the last annotated tag in master (i.e. the output of git describe)

[mdinino]

OK. That works.

On Tue, Jul 19, 2016 at 11:06 AM, Brian @ edX notifications@github.com
wrote:

The version int is only important for Google Play distribution, our
testing builds have no reason to depend on it's value or to increment it. I
think it is in our best interest to forget it exists, and rely only on the
semantic version.

Like Chris said, we could easily customize the nightly build (or any
build) to use a particular version if we need to. If building off master
right now, it will use the last annotated tag in master (i.e. the output of git
describe)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/edx/edx-app-android/pull/774#issuecomment-233662536,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AR10Twv0tEBhDKGXg_AxIWSfUoCB5N0Yks5qXOfigaJpZM4JNpnJ
.

Regards,

Marc DiNino
Android Engineer
EDX

[ghost]

Note, this strategy also implies that every submission to Google Play should (in fact, MUST) be accompanied by an increase in the semantic versionName string.

I think that's a good thing, but please speak up if you foresee any issue with that. I've used this strategy for other apps in the past without issue.

[mdinino]

It think it should be OK.

On Tue, Jul 19, 2016 at 11:10 AM, Brian @ edX notifications@github.com
wrote:

Note, this strategy also implies that every submission to Google Play
should (in fact, MUST) be accompanied by an increase in the semantic
versionName string.

I think that's a good thing, but please speak up if you foresee any issue
with that. I've used this strategy for other apps in the past without issue.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/edx/edx-app-android/pull/774#issuecomment-233663959,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AR10TzaovvQ1RNfJ4pYdTqulrEyo2M3yks5qXOjpgaJpZM4JNpnJ
.

Regards,

Marc DiNino
Android Engineer
EDX

[BenjiLee]

👍