ok. What can I say.

I would like to treat QuickOPC like framework e.g. NET.
That means when I have version 4.5 and I update to 4.5.1 I can be
sure that this version is BINARY COMPATIBILITY.

It is terrible practice that each version (also with minor number)
could bring breaking API changes. Because was made refactoring e.g.
some classes was moved to another namepsace.

It could be do in internal framework not in public framework. And it should marked by changes major version.

QuickOPC is working in industrial environment. Do you know procedures in pharmacy area?
Each changes in software has go throw very expensive acceptation process.
Very often this acceptation is doing by external companies.

-- Who should pay that I need to upgrade QuickOPC to fix some problem and next I have to
-- rebuild of sources because someone decide that this class would be look better in other namespace?

Of course it is rhetoric question. I hope that my explanation provide view how
this problem could look in proactive environment.

========
And another: Not only API breaking changes is problem, but also changes of API behavior.
Could provide problems which could be difficult to diagnose.

========
Beside it, I like QuickOPC with several reason. It good solution to simplify opc world.
But please consider my remarks.
Thank you.

In my opinion is not professional.
Would be nice that you share my opinion to some leader of project.

I could not imagine this kind situation in bigger project in Automotive .

Would be nice to consider Long Term version which should be supported longer time like in linux distribution e.g. : Ubuntu.

Ok. I understand. But please consider.
1. Do you have information about release notes for each version?
Also with breaking changes.

2. What about binary compatibility and hotfix?

Version: v5.34.177.1 or maybe 5.33 was provided hot fix for exception with loading image Amd64 in web application.

could not load file or assembly 'OpcLabs.EasyOpcClassicRaw.amd64' or one of its dependencies. An attempt was made to load

How I could update quick opc (with hotfix) without rebuilding whole sources which use quickopc?
(I used in assembles Specify Version = false).

We have to be aware that in productive environment is very short time to make update.
This kind of breaking API could make hell. I need this version (because of hotfix) but this version is breaking changes.

Why did you break API e.g.:

DAQuality

v5.32.1063.1
public bool IsGood();
v5.34.177.1
public bool IsGood { get; }

Which number in version could means braking change?