Should untouched repos get an updated version number at end of sprint?

Question

Lets say we have a large project which is split across multuple repos. We have something like

shared-functionality-repo GUI-repo REST-server-repo supporting-framework-we-plan-to-release-seperate-repo Communication-library-for-3-parties-repo etc...

During a spring one of these repos, maybe the third party comms, is not touched and code doesn't change, but all the other repos get changed. At the end of the sprint we want to wrap up and tag everything for release, and update version numbers.

What is considered the best practice for my untouched repo? On the one hand it feels odd giving it a new version number, since nothing has really changed. On the other hand we need/want to point the repo to the newer version of repos it's dependent on, which updates the pom. Not updating the version number seems likely to lead to some odd inconsistent state at that point. Currently we don't update anything, but that ends with untouched library ultimately using some old version of code because it's still pointing to our shared functionality repo that's 4 sprints old...

What is the recommended approach for versifying int his case?

Answer 1

Your current approach is correct. As you hinted at, you want to avoid fragmentation. By keeping the version numbers consistent across all your repositories, it is simple to roll everything back to a previous version for any reason. Once you start carrying different version numbers, you've introduced one more thing to track.

Another way to look at it, is to ask what you are losing? A trivial amount of bytes in your repos to add another tag, in the case of Git? I suppose if you're using a different revision control system that maintains separate copies of the code for branches and you keep a branch for each release, you may be using more space, but disk space is inexpensive these days.

The word "consistency" is occasionally overrated in this field, but it's certainly justified in this case. There's nothing to gain by not keeping the release numbers consistent across your repos.

Alternatively, if you do want to get rid of the "odd" feeling of changing version numbers in repos where nothing changed, you could apply an approach I'm currently using to maintain an integration repository that has no control over the repositories it pulls from. Within this integration repository, we maintain a manifest that points to all of its remotes and their revisions that are used for each release. The release version of the integration repository is completely abstracted from the remote repository's revisions. The manifest is updated with every release. This allows us to roll back our integration repo and build from any point - the build scripts use the manifest to pull from the correct revision of the remote repositories.

There are two key points to this approach:

1. The manifest is under revision control in the integration repository. Don't make your repository consumers look somewhere else for this information where it might get out of sync.
2. The remote repositories' release numbers are entirely separate from the integration repository's. Updating the remote's release number to match the integration repository's only when it changes is going to be confusing - either make them all the same on every release, or give them all completely independent release numbers.