In my group we are debating whether to version each one of our system components or not. While I find many talk about "how" to version each component (semver for example) I don't find enough reasoning to do that.

What I can think about is that If a version of some component appears to be faulty, we can always use an older, stable version of the component.

If we didn't keep updating a version before each merge, we should have rollback all the code changes to build the component in its previous state again instead of just using the stored old versioned component.

Is this the only reason? Are there more?

Please notice, the project is an testing automation project. Each module is a separate repository on Git.

Some of the components serves as infrastructure for others!

The automation runs on Jenkins.



Another wonder would be: Does it have the same effect like tagging the branch after any merge for quick rollbackl purpose?

  • 5
    Can you elaborate on your context? Do you have strict traceability requirements? Are you using (or moving toward) continuous deployment? Are your components (micro)services or are they part of a monolithic deployment? These are just a few of the things that I consider when talking about versioning schemes.
    – Thomas Owens
    Jul 22, 2021 at 12:26
  • @ThomasOwens I updated my question with more details.
    – dushkin
    Jul 22, 2021 at 12:41
  • Will you have multiple versions in production at any time? Jul 23, 2021 at 8:43
  • @ThorbjørnRavnAndersen This is an automation project, not related to production. Did I understand correctly you question?
    – dushkin
    Jul 24, 2021 at 9:58
  • I don't understand why you want to version then? Just keep track of corresponding git sha1's for working versions for rollback then? Jul 24, 2021 at 10:01

4 Answers 4


If the components are independent to some degree, then it might make sense for the system version to declare the component versions that it's composed from, e.g. to create a higher next system version from rolling back one faulty component to a previous release, and keeping the other ones untouched. Of course, then you need to be able to identify these versions independently.

But if development of the components is tightly coupled, so that such a version mixture won't work, there's no need for individual component versioning, and you can simply use one common version number.

Another hint might come from the setup of your build automation. It's typically a good idea to have the build pipeline increment the version number. So, if a single pipeline builds all components, they naturally end up with a common version number. If you have individual pipelines for the components (plus one for the whole system), triggered individually, each pipeline will produce its own component version.

  • 3
    Excellent advice! +1 ; looking at semver’s declared purpose (dependency management) the independence is really a key element here. But if all these components, even if relatively independent are meant to be kept and distributed together and are developed by the same team, there’s little incentive for the versioning overhead. If on the other side components are meant to be reused in different context, or developed by independent teams, separate versioning is strongly recommended imho.
    – Christophe
    Jul 22, 2021 at 13:16

If we didn't keep updating a version before each merge, we should have rollback all the code changes to build the component in its previous state again instead of just using the stored old versioned component.

Which previous state? How old? Those are the questions versioning answers. If you can be sure this issue comes up fast enough that the answers to those questions are obvious then versioning isn't really an issue. The problem is now you're in the business of predicting the future.

Version conflicts can happen when you deploy anything less than the whole system. And by whole system I'm including any serialized components. You know, those things the customer thinks of as their data that they made sure to backup before doing your install. This isn't just an issue when two independent systems are trying to communicate. This comes up any time your component's life cycle out lasts it's version being the current version.

If you need Foo 2.0 but get Foo 1.0 it's nice that you can tell the difference. And it's nice that you didn't have to come up with a new name for the new version, like say Bar.


Component Versioning - What is the importance?

Short answer: Versioning is for communication purposes.

Mostly answering questions like:

  • What was the state of software which is currently deployed?
  • What should be the state of dependencies making this software work

or if your software itself is used externally

  • What state of your software was used?


To indicate which state was used there are several schemas:

e.g. using animal names and numbers like ubuntu or using names of snacks like Android up to semver

What makes sense depends on your (or other people's needs).

If you are developing an inhouse product with components only used inhouse the commit-hash or a simple tag may be enough of versioning scheme. The differentiation of semver with its major, minor patch scheme indicate when your system may break and when it should be safe.

But as long as you have a definition of your build artefact (this build consists of these components and their respective commits/tags) everything should be okay.

Another idea to structure your inhouse system could be a Monorepo, where everything in one branch works with components being in the same branch.

Of course if you are developing for the outside world adopting a scheme like semver for your components may be a smart move.


Note that between Component Versioning - What is the importance? and Is rolling back code the only reason? Are there more? are quite different questions.

I will address the answer to the last question. So, to the question Is rolling back code the only reason? Are there more? The answer is yes. There could be as many reasons as purposes. While rolling back buggy code is a common one, I can think 2 more that I have seen quite often

The first one is long term support. If you have no control over systems that use your components, if you can not keep them up to update, it's likely there'll be segmentation by version. In other words, several systems adopting one or another version of the components.

While imposing the "latest version" policy is the easier solution for you, it's not always the best policy for the consumer. Maybe, because it could be impossible (or unfeasible) to do.

Imagine Component_A-1.0 built to be compatible with JRE 1.5 or later and the same component Component_A-8.0 only compatible with JRE 1.8 or later (for whatever reason). Some systems might not be in a position to migrate to JRE 1.8 and yet want its old Component_A-1.0 dependency to be stable (at least for a reasonable period of time).

The second one is customized components. It's not rare that once you have what you think is a very generic component, a new customer or dev team ask you for new features or changes. Here the versioning is not a mere semversion, but it's still versioning and a much better one than bloating the code with loads of if_else statements.

Basically, a reason for versioning could be having different development lines for the same component, each of which with its own life cycle.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.