All tasks only increment patch version (in submodules) about gradle-release-plugin

[netzwerg]

The tasks differ in their versioning strategies when creating the tagged release. After that, they all increment the patch portion in preparation for the next SNAPSHOT development phase (this happens in the "offending line").

You should thus see the correctly incremented minor/major version reflected in the release tag. Alternatively, you can checkout the tagged release commit and inspect version.txt. Your HEAD state will already contain the next SNAPSHOT version -- just like you observed.

Please refer to the README for a description of all involved release steps.

If you still think that the plugin is not behaving as it should, please provide your build script and detailed steps on how to reproduce the problem.

[mattbrown]

I've created a test repo here: https://github.com/mattbrown/gradle-release-test
Tests I ran:

• Release
  • Version.txt is 0.0.0
  • Tag prefix is "release_v"
  • command: gradle testSubModule:release
• Result
  • Tag is "release_v0.0.0"
    • This was what I expected
  • Version.txt is now 0.0.1-SNAPSHOT
    • This is what I expected
• Release Minor Version
  • Version.txt is 0.0.1-SNAPSHOT
  • Tag prefix is "releaseminor_v"
  • command: gradle testSubModule:releaseMinorVersion
• Result
  • Tag is "releaseminor_v0.0.1"
    • This was what I expected
  • Version.txt is now 0.0.2-SNAPSHOT
    • Expected was 0.1.1-SNAPSHOT
• Release Major Version
  • Version.txt is 0.0.2-SNAPSHOT
  • Tag prefix is "releasemajor_v"
  • command: gradle testSubModule:releaseMajorVersion
• Result
  • Tag is "releasemajor_v0.0.2"
    • This was what I expected
  • Version.txt is now 0.0.3-SNAPSHOT
    • Expected was 1.0.1-SNAPSHOT

Am I misinterpreting what these different tasks are supposed to accomplish?
Please let me know if any more information would be helpful.

PS: I apologize for the "offending line" description

[netzwerg]

Thank you for the test repo and the detailed report -- this helps a lot!

The plugin should only ever be applied to the root project of a multi-module build. It does not make sense to have different version.txt files in subprojects, since the plugin manages versions and tags on the basis of the complete Git repo.

I have sent you a pull request with the necessary changes. I successfully called ./gradlew release, ./gradlew releaseMinorVersion and ./gradlew releaseMajorVersion (from the root project). They all behaved according to my expectations. The corresponding commits/tags are all included in the PR, so please let me know if you still see any issues.

[mattbrown]

Ah, I see, that makes sense.

It certainly would be helpful for my use-case to be able to apply the tasks to submodules of my repo. I have multiple modules each representing its own service under the same repo so that I can deploy each service separately or together depending on the client/environment need.

Would you be open to a pull request that would allow for the expected behavior in submodules that I outlined in my test?

[Pytry]

Being able to apply a different version to sub-projects may be useful for some people, but it depends on your philosophy on versions.

Admittedly I've only just begun delving into this plugin, but I love the minimalist approach. So correct me if I'm wrong on how it works or how it should do things.

I like that this keeps the versions of all sub-projects in-sync. This will occur even if there were no changes in a sub-project. When working on a system/suite of business services and applications, this is very useful. It helps everyone to know which version of each project is compatible with the other.

The disadvantage to this approach, is that production releases are then more involved, since you end up having to release multiple projects even though nothing has technically changed.

I counter this by using a standard deployment script or defining targets in a CI server, which removes the human error from the configuration and deployment process.

You could argue (and rightfully so) that compatibility is defined by your dependencies. However, I would suggest that it becomes difficult to know when to update a projects dependencies to newer versions in your services and applicaitons suite if the versions are not always in-sync.

When each sub-project is actually a standalone deliverable, with no interaction with other sub-projects, it would be useful to be able to specify a version for each one as @mattbrown is asking.

But the counter to this, is if they really have no relation to one another, why organize them in a project/sub-project manner in a single repository and build? This is not rhetorical; I'm asking what your thoughts are.

The advantage to this approach as I see it, is that when only one sub-project is modified you only have to deploy that one project.

Another advantage to having them all grouped together into one build, is that it provides a single repository and tool for managing each project, even though they may not actually have dependencies on each other.

I'm also curious as to what approach/principle this plugin is intended to take in this manner. Is the plugin intended to be opinionated on how a project is maintained and focused in it's functionality? Or is it intended to be a jack-of-all-trades like the maven release plugin?

If the plugin is opinionated, then maybe you do not want to change the current behavior, and instead users can simply include the plugin in each sub-project at the level for which they intend for the versions to be managed. So in other words, if you do not want your root project to keep the versions in-sync for all sub-projects, then do not include the plugin at that level. This would(should_) keep the project simple, and should still work for @mattbrown s use case. (_I have not tested this functionality, so this is an assumption on my part).

If it's a jack-of-all-trades, or somewhere in between the two, then it makes sense to allow users to specify different versions for each sub-project as well as add other copnfigurable aspects and functionality.

[netzwerg]

Thanks for the nice comment, @Pytry !

The only purpose of this plugin is to solve people's problems, so I am very open to any suggestions or PRs! IMHO the plugin should follow the general Gradle principles: Simple things should be simple, complex things should be possible.

@mattbrown : If with "submodules" you mean true Git submodules, I would guess that using different versions for every submodule is already possible. As @Pytry has pointed out, it should be possible to include the plugin in each submodule (and not in the root project). I am not using Git submodules/-trees in any of my projects, so no guarantees here. If it doesn't work yet, I'd happily accept a PR.

If however you meant Gradle sub-projects in the same repo, I am hesitant to support multiple versions. Sub-projects are essentially just sub-folders. Git does not track tags on the level of folders, but on the complete repo, so these sub-projects-specific versions would always leak out to the global/root project.

Personally, I would only every group projects into a multi-project build under one repo if these projects truly belong together in the sense that they share the same version/tag.

[mattbrown]

@netzwerg @Pytry based on your comments, I think I'll close this issue. I would in general agree with the assertion that (in general) the version for an application should be repository wide.