0

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.

  • 2
    At the risk of seeming a bit thick, what is "the obvious?" I work on systems all the time that use Nuget packages, and since each package has a different versioning scheme, trying to get them to sing to the same sheet of versioning music is nigh impossible. – Robert Harvey Oct 2 '18 at 15:02
  • 1
    is there any reason to keep track of different version numbers of each component? -- In my world, that's already done for me. I can look at the Nuget package manager any time I want and it will tell me which version of which component is installed. I can also examine DLL versions. – Robert Harvey Oct 2 '18 at 15:07
  • 2
    Are you trying to solve a specific, well-defined software design problem that you're currently having? That's what we're about here. – Robert Harvey Oct 2 '18 at 15:08
  • 1
    Well, if none of the components are being shared between "editions," I can't think of any good reason why you would need to track versions of those components at all. They are simply part of the whole edition. That would get your versioning problem down to 20 variations. Your problem seems less to do with versioning than with the way your "editions" and "components" are organized; something doesn't feel right there. – Robert Harvey Oct 2 '18 at 15:21
  • 1
    @DanWilson I don't know if I am not explaining this correctly; Component A will always be for customer X and for no other. This component, will forever be bound to the "edition" of the software that is being released for customer X; it will not be separated or exchanged. – Lefteris008 Oct 2 '18 at 15:44
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.

0

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

  • Correct, but this is only when you have a "pool" of components and embed different versions of them, on different applications. In my case, we are talking for the same "chunks" that constitute an edition of the application. These components are not developed separately but along with the edition and exist inside it, being unique to it. So, is there any reason to version them beside the fact that this is considered good practice? – Lefteris008 Oct 2 '18 at 15:57
  • no. same application, different versions, installed either over time or in different locations – Ewan Oct 2 '18 at 16:24
  • In my case, there's no scenario of same application, different versions. Once a fix is released, the previous version becomes obsolete; the fix is deployed at once (or at a predefined time) on all machines that run this software. – Lefteris008 Oct 2 '18 at 16:32
  • ok. so you do have multiple versions over time on multiple machines and you do deploy over the top. file versioning can help you when something goes wrong and you want to know if file A is the same as file A' – Ewan Oct 2 '18 at 17:01
  • Ok, that is a valid argument. – Lefteris008 Oct 2 '18 at 17:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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