-1

I am new to an organization that has a release version number for their vision software and a different release version number for the supporting functionality (dvr, provisioning, etc) around that vision software. It is straight C code - everything is global, very tightly coupled and the components do not compile separately. So everything in the directory vision gets one release number - everything else gets another one. BUT IT IS DELIVERED AS THE SAME EXECUTABLE. The reason they do this is if they have to do a bug fix in the provisioning code, they tell their customers that they are just releasing the provisioning code - ie, no changes to the vision code. But there are global variables shared between these components. It would be very easy for a change in one section to negatively affect the other (change timing, introduce a null pointer, etc).

I am going to come up with an argument that this is a bad practice - just wondering how bad it is. My question is - How wrong is this? Has anyone out there seen something like this done in the industry? Are there any benefits to doing this? I personally think it is a horrible practice and see no benefit to it and they are misleading their customers..But maybe I am missing something...

  • 1
    It's hard to tell from your question why this might be necessary, but sometimes companies have to do weird things to appease customer requirements that are... shall we say, irrational? – Robert Harvey Apr 2 '18 at 15:26
0

The monolithic delivery can be done fairly safe with proper QA. It makes the versioning of the internal components rather irrelevant, since what's actually delivered is the combination of all the internal versions - as long as one of them changes the combination and hence the monolith "version" technically changes as well.

If you want, that wouldn't be different than, let's say, a library's code not getting an API version change for each an every code changes it receives: while a system using the library might happily accept the updated code because its matching API version, that doesn't mean there are zero chances of it still functioning as it did before (for better or worse).

Regardless of the above reasoning, IMHO it's still not a great practice as it can cause confusion, both internally and on the customer side. For example, say a customer reports an issue for version X of the vision software. To be certain of the actual monolith version context, customer support would need to determine the provisioning version as well.

As for the story told to customers - there might be valid business reasons behind it (that can include historical reasons as well) - after all almost everything is about perception these days.

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.