❓ Future of 1.0 version ❓

[sbernard31]

Wakaama 1.0 is an implementation of LWM2M 1.0.x

Current master branch aims to target a LWM2M 1.1.x.
Thismaster branch will probably break 1.0 API and so will be released as a 2.0 version (or higher if needed)

The question is : What should we do with the 1.0, do we plan to still maintain it (at least bug fix release) ?

@sbertin-telular, @rettichschnidi any though about this ?

Feedback from community would also be really appreciated 🙏

[rettichschnidi]

Personally, I have no interest in maintaining a 1.x release. Catching up with LWM2M 1.1+ and not being constrained by the existing API seems much more attractive to me.
We should only put any efforts into a new 1.x release once someone shows up and is willing to contribute to it.

[sbertin-telular]

Unless there is strong community demand I also don't have interest in maintaining the 1.0 branch.

[jvermillard]

On sierra side, I don't mind breaking the API, but having the client being able to support both 1.0 and 1.1 (if feasable at all) would be interesting since I suspect we will need to handle both cases in the wild

[sbertin-telular]

My 1.1 changes have #defines to select which LWM2M version will be supported. This could be important for more constrained devices to limit memory requirements if only 1.0 features are required.

[tuve]

I think the 1.0 version needs to be maintained, at least for bug fixes. On really constrained devices it might not be possible to migrate to LWM2M 1.1.x with a (likely) increased memory footprint just to get a bugfix. Also The LWM2M 1.0.x support is not complete in the Wakaama 1.0 release, object versioning support as an example and things like the block transfer support is an addition to coap and does not depend on the lwm2m version (the later should probably go into version 2.0) Maybe do as @sbertin-telular with defines is enough?

[sbernard31]

I added Security policy (#491 (comment))
This thread is probably the good place to deciding which version is concerned by this policy.
The idea is to have something like :

Version	Supported
5.1.x	✅
5.0.x	❌
4.0.x	✅
< 4.0	❌

[jvermillard]

Maybe do as @sbertin-telular with defines is enough?

I would go for that, a single branch that support both version, now that does mean we need to know how much violence we want to do to the current wakaama version.
due to the lack of completness on some core feature like blockwise transfer I think it will be hard to move forward without breaking some APIs

[sbertin-telular]

The #defines I have are more for features than for API compatibility. I know some of my changes are not compatible with the 1.0 API.

[sbernard31]

IF we want to keep a Wakaama version for LWM2M 1.0, it seems there is 2 solutions :

1. try to support this in the same branch (master)
2. try to create a dedicated 1.x branch.

(Personally, I didn't know the code enough to be sure that 1. is doable)

About API compatibility, this is another question :

• I guess keeping API compatibility for master will be too hard. (To support LWM2M 1.1, I guess breaking API will be hard to avoid)
• eventually keeping API compatibility for a 1.x branch which targets only LWM2M 1.0 is maybe doable.
• it is also possible to create a 1.x branch which targets LWM2M 1.0 only without API compatibility. As long as we document/communicate on this.

[LukasKarel]

We are currently using wakaama with LWM2M version 1.0. We would hope if there is some code base maintained for version 1.0.
But we are considering updating to 1.1 to use OSCORE in the future.
My master thesis will be about OSCORE. My (future) knowledge might help integrating OSCORE into wakaama.

[rettichschnidi]

@waynebeaton has volunteered to apply for CVE [1] now that [2] has been fixed by #640.

If anyone is really interested in maintaining version 1.0, now would be a great time - please chime in here and in [2].

If nobody steps up, Wakaama users are pretty much forced to update to master and we should officially acknowledge that version 1.0 is not supported at all.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=577968#c14
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=577968

[sbernard31]

The corresponding CVE is : CVE-2021-41040.