Return to Question

Because we are actively dealing with physical devices, each "edition" consists of separate components that in 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.

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.

Because we are actively dealing with physical devices, each "edition" consists of separate components that 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.

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.

Because we are actively dealing with physical devices, each "edition" consists of separate components that in 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.

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.

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 talk to each device. 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.

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 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.