All three sub-modules publish their own artifacts.
Say we're now on version 0.6.0, and at version 0.7.0 only release and semantic-versioning modules have changed, yet we are going to create a release version for all 3 sub-modules. In addition, the spec isn't going to change often at all, so why would we create new versions for it every time we update one of the other two?
Some questions that need to be answered:
releases are based on git tags, we can't have a separate tag for each submodule
a possible solution would be to set individual versions for each submodule in gradle (based on some configuration), but version the whole project would be versioned in git
it could be a bit confusing, because git tag v0.7.0 could potentially mean release:0.7.0 and at the same time spec:0.6.0
there will be "version jumps", e.g. last version of semver was 0.6.0 and next is 0.8.0
I don't really see a way to work around this, so it's something that either needs to be accepted or this issue can be abandoned
would probably need to shadow the project-type dependencies?
how to detect if the submodule has changed between last and next versions? git diff with a (configurable) submodule path (defaults to src/main dir of the submodule)?
Consider this project's structure:
All three sub-modules publish their own artifacts. Say we're now on version 0.6.0, and at version 0.7.0 only
release
andsemantic-versioning
modules have changed, yet we are going to create a release version for all 3 sub-modules. In addition, thespec
isn't going to change often at all, so why would we create new versions for it every time we update one of the other two?Some questions that need to be answered:
v0.7.0
could potentially meanrelease:0.7.0
and at the same timespec:0.6.0
semver
was 0.6.0 and next is 0.8.0project
-type dependencies?src/main
dir of the submodule)?