Hello everyone,<p>I was wondering how people on HN manage their versioning and releasing for Android applications when using Gradle, especially when combined with a workflow such as git-flow.<p>I find the existing release plugins quite immature on Gradle for handling git-flow, and I have been unable to find a workflow (I could really do with a simpler one than Git Flow) that would enable us to version and release our applications in a simple and predictive mannger. I thought HN would be a great place to ask for advice.<p>Illustrating my issue, I work with a team on Android applications. As of today we follow the Git Flow process and use the gradle-release plugin from Research Gate https:&#x2F;&#x2F;github.com&#x2F;researchgate&#x2F;gradle-release. I regret the lack of semantic versioning (that prevents us from knowing what version of what application is running on a given device in our development and staging environment), as well as the difficulty to have several versions to co-exist at a given time. Indeed, having a release candidate on a release branch living in parallel to the next development version on the develop branch systematically leads to conflict when releasing and merging back. This prevents us from having everything automated on our CI server, and requires a lot of manual operations.<p>I have investigated some of the semantic versioning &amp; releasing plugins for Gradle such as https:&#x2F;&#x2F;github.com&#x2F;ajoberstar&#x2F;gradle-git and https:&#x2F;&#x2F;github.com&#x2F;nebula-plugins&#x2F;nebula-release-plugin, but it sounds like they use the closest tag to the HEAD to determine the current version so it would not improve our current situation much.<p>I would be really keen to hear of how you guys handle this in your projects. If you have inputs on effective workflow for Android application (the simpler the better), or ways to make our current workflow work with Gradle, I would be really happy to hear about it.<p>Thank you.
Ask HN: How do you manage versioning and releasing with Gradle?