OPC UA 1.05 and Milo 1.0.0 Release

[kevinherron]

Parent ticket for all 1.0 sub-tasks and issues.

• ECC Security Profiles
• Roles and Permissions #1248
• DynamicStructCodec
• JsonStructCodec
• Server-side Support for dynamic/run-time defined types
• Codegen artifacts from latest models
• Adopt and apply Google-ish code style, re-enable checkstyle
• Convert existing TestNG tests to JUnit 5
• Migrate annotations to JSpecify?
• Convert AddressSpace to blocking API #1243

[apupier]

provided #1263 for the migration from testNG to JUnit 5

[andvasp]

Hi @kevinherron,

Since there are breaking changes in this version (specially #1223), would it not be good to have a version 0.7 based on 1.0?

Thanks!

[kevinherron]

I don't see the point in that.

[andvasp]

The point is that with a published version it will be easier to use (migrate our code), test and even suggest any modifications to the API prior to 1.0, which should be more stable. And you don't need to worry about all the requirements to release version 1.0.

A lot of other systems can enjoy this version too as mentioned here #1098.

Why not incremental releases?

Anyway thanks for the great job you are doing here!

[kevinherron]

You can develop against dev/1.0 (we are currently doing this at $WORK for our next big release).

I don't want to do an intermediate release with a bunch of breaking changes, when it's a certainty that 1.0 will introduce more. It's just extra work I'd be asking people to deal with. 1.0 will be one big ugly migration effort which you can start at any time you like by developing against dev/1.0.

When 1.0 is released I have no intention of supporting any 0.x releases, which will be another pain point for anyone who migrated to a hypothetical 0.7.x release.

[kevinherron]

Sorry for the gruff response, I've got a lot on my plate between now and the end of the year 😬

[andvasp]

Don't worry. I didn't consider it as a rugged response.

[stegal-bh]

Hi guys, any update about ETA for the 1.0.0 release ?

[kevinherron]

Nobody but me occasionally working on this. Maybe something in January? Who knows.

Anybody who has time to build and test with dev/1.0 branch would be helping me out.

[andvasp]

Hi @kevinherron!

I will try to test it.

[hyslopc]

@kevinherron FYI we moved our client from 0.6.14 to 1.0.0 without encountering any major issues. I definitely prefer the 1.0 API.

[kevinherron]

@kevinherron FYI we moved our client from 0.6.14 to 1.0.0 without encountering any major issues. I definitely prefer the 1.0 API.

@hyslopc thanks for the feedback! I know it's not a drop-in replacement, but I tried to use the last 5+ years of supporting the 0.x APIs to come up with something that is easier to figure out and still supports most/all use cases.

One of the biggest things I learned is that most people prefer a simple blocking API to an asynchronous/non-blocking API, and even that many users don't really understand how to use an asynchronous API or compose CompletableFuture results.

(not to say you didn't understand, just a general observation)