OPC UA 1.05 and Milo 1.0.0 Release

[kevinherron]

trafficstars

Parent ticket for all 1.0 sub-tasks and issues.

• [ ] ECC Security Profiles
• [x] #1248
• [ ] DynamicStructCodec
• [x] 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?
• [x] #1243

[kevinherron]

ETA... late 2023, early 2024. Definitely not before the Germany OPC interop event in October.

[perivarbakke]

ETA... late 2023, early 2024. Definitely not before the Germany OPC interop event in October.

@kevinherron Can we still expect this release early 2024 (Q1)?

[kevinherron]

I don't know, I'm about to resume working on it. There's a chance it could be ready by April, after I've attended the OPC interoperability event in March.

The time I thought was going to be allocated to working on it at my job vs. on the side got reallocated to something higher priority.

[apupier]

provided https://github.com/eclipse/milo/pull/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.