Besides the obvious is there any good reason to version separate components under one general release?

Question

I am working at a company that deals with software specifically designed for 3rd-party customers in a Business-To-Business scheme. We have variations of a large software, that for every customer get specialized and ultimately we end up with different editions of the same parent program.

Because we are actively dealing with physical devices, each "edition" consists of separate components that in one way or another, talk to each device, unique to it. In the current form, every time we add a new feature to a component or fix a bug in some of them, we release a newer version of the entire program (due to apparent technical limitations in separating the components and releasing single updates with them), that contains the current version plus the new component.

To make things simple, let's split the program:

• UI section, that is version 2.0.0.1.
• Component A, that is version 1.0.2.7.
• Component B, that is version 1.0.3.9.
• Component C, that is version 1.0.0.1.

Because our changes are mainly focused in the UI section, it's more common the whole application to take the version of the UI component; so in our example, it is version 2.0.0.1. If I make a change to Component A, I bump its version to 1.0.2.8 (let's say it was a minor bug fix), I tag the entire solution and so my application will be version 2.0.0.2.

Let us also take into account that we are not exchanging separate components to other teams that work to different "editions" of the parent application and that the customer will ultimately take a single executable of his customized version (2.0.0.2), regardless of the changes I put inside.

My question is this: since the application at all times is considered one and whole, is there any reason to keep track of different version numbers of each component? Surely, this will help internally the developers to know how old or new a component is (since everything starts from 1.0.0.1), relatively to other parts of the application but this can also be known by browsing the repository inside a component's source code. Are there any other arguments for this strategy?

Side note

Because maybe it has not become evident from the above question: the components are not exchangeable. They are not found to any other "edition" of the parent application, except the one that were initially designed for. Therefore there will not be a customer Z in the future, roaring on why we put to his edition Component A version 3.0.0.1 as his own variation supports up to version 1.5.0.1. Of course there is a set of common components, but I am not talking about them. These are maintained in a completely different source tree/project, from an entirely different team. My question is relevant only for the chunks of an "edition" that constitute its own unique components.

Side note 2

I know that changing a few KBs of code in Component A and then prepping up an entire new release that weights a few hundreds of MBs because you are not employing delta releases, is at the very least lame. If the components were being released separately, then versioning would make perfect sense. But my company is not the only one that goes with fat releases and, while I don't applaud this technique, I can understand the reasons that a few years back made them choose this over the other one.

What I'm trying to identify is whether there's another meaningful but otherwise hidden reason to keep tagging them, with them being indivisible from the main app.

Answer 1

If every component is actually separate, reusable and not tightly coupled to the app that uses it, the version of the components should be updated when a bug fix or a new feature is released.

Imagine that you have 3 APIs that you call from your app. You don't know the internals of each API but you only know the public functions each one provides. If the developer of one API issues an update, he updates its version. Now you, the user should not see anything change in your code (if this is just a bug or new release that does not deprecate previous versions). In this scenario one can argue that you should not even update your version.

If the components are specific for this application and cannot be used anywhere else, it may be reasonable to bump the version only to know that there is an update in the whole package. It may be irrelevant but there are developers that keep the number that denotes the minor version of the software, even if the major version has already changed, only to make it clear that in this version there exist no bugs from a potential merge with a previous version. E.g.

From 1.0.23 to 2.0.23

As others already have stated it depends on the way you use your components.

Answer 2

Couple of things ive seen in live envrionments.

1. Deployment copying over old version and not overwriting some of the files correctly.

2. Different dll versions for different OS versions, even though the product is the same version.

3. Applying a binary hotfix. Only affected dll is changed