Is there a recommended way to manage dynamic versions when a you create a branch for release?
We currently declare all dependencies using particular revisions e.g. ‘ois:serverUtils:1.0’. We have several projects that are treated as libraries and published into Ivy and want to avoid the manual step of updating the build.gradle files in other projects which depend on these types of libraries.
Using dynamic revisions e.g. latest-integration would solve this, however this creates a problem when we create a branch (in Subversion) for a release. For the branches we need to put these dynamic versions back to the particular revisions. Is there any recommended way to do this? I’m thinking I’ll need to write my own script to do this (but haven’t figured out how yet).
What are other people doing to manage dynamic versions when creating branches?
Does Gradle provide any way to handle this? Does anyone know if a repository manager like Artifactory has any features to help with this, or plug-ins in Jenkins?
Yes, this was question I had in my mind when I evaluated Gradle.
I’ve done my own build system years ago with Ant+Ivy. In the main branch, we had some latest.integration or latest.milestone revisions. The system had a command “ant branch” which would create the branch and assign the current static revisions to the ivy.xmls in the branch. It was relatively easy with ivy.xml because it is in xml format. The script basically did an Ivy delivery, which created an ivy.xml with the static revisions, and then did some xml manipulation with XMLTask.
I don’t know a general solution for this in Gradle because there are many different ways to set the version in the code.
Another related question is, how would you implement something like Maven’s Versions Plugin in Gradle?
Where do you get the “current static revisions” from? If you can get to them, you can either look them up dynamically from the build script, or externalize version numbers from the build script and change the externalized information.
You might declare the dependencies using version ranges on the release branch, e.g. ‘[1.0, 2)’. We would probably chose this approach for our release branches, instead of using static versions. In our case, after the release, products might also release fixes, so if one uses static versions, again will have to update them whenever corresponding products release a fix.