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.

I am the project leader.

I disagree with your argument; however the discussion is out of scope of technical support.

Best regards

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.

Dear Sir,

ad 1: The most important changes (but not necessarily all changes) are listed in the "What's New" document that comes with each version. The change that you are referring *is* documented there.

ad 2: Binary compatibility or hot-fixing was never intended and will not be supported, and is not even guaranteed between different builds of the same version.

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

You can not.

Best regards

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.

Generally, any version number change can mean a change in the API. By "the version", in "a.b.c.d", we mean the first two elements, i.e. "a.b". We do not do breaking changes for the fun of it (in fact, we try to avoid them if possible), but they are needed in order to achieve higher consistency during the future life of the product.

Best regards

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?