Long-term support

[Smiesek]

Hi everyone,

Do you plan to continue supporting the C++ version of Iceoryx? As far as I can see, the latest version mentioned on the main website dates back to 2023, although this repository includes tags for newer versions like 2.0.6. Unfortunately, activity in the repository seems to have stopped. Is there a plan for releasing version 3.0 and continuing active development?

Regards,
Tomasz

[elBoberido]

@Smiesek there are currently ongoing discussions whether we should have another major release of iceoryx classic. There are not many new features compared to v2.0.6. Most notably it's 32 bit support and the option to run multiple RouDi in parallel. The latter is hidden behind an experimental feature flag and is currently only available via the C++ API. All major bugfixes are also ported to the v2.0 branch. We will continue to support iceoryx classic for some time but there will be no new features.

The main focus has shifted to iceoryx2. The next release of iceoryx2, which will be done this weekend, will introduce the request-response messaging. That release will surpass iceoryx classic in functionality and also fixes some critical bugs which we ware not able to fix in iceoryx classic due to it's design.

Is iceoryx2 an option for you? If not, what would be required to make it a viable option?

[Smiesek]

In general, I need a stable, well-tested, and ready-to-use framework for communication between multiple processes in a C/C++ environment. The publish-subscribe and request-response patterns are sufficient for my needs.
I noticed that Iceoryx2 currently offers a Rust API (according to your website), and in general, it appears to be in a beta phase.

I have a few questions:

1. What is the current status of the C++ API in Iceoryx2, and of the library itself?
2. What does "Works with a restricted security and safety feature set" mean in the context of the Linux platform?
3. What are the critical bugs in Iceoryx? Is there a publicly available list?
4. In your opinion, is it easy to upgrade from Iceoryx to Iceoryx2, or are they completely different libraries?

This library looks very promising. Overall, great job! 👍

[mossmaurice]

@Smiesek

Thanks for raising this discussion and for your interest in iceoryx2! It's an important question, and as @elBoberido mentioned, it was discussed quite vividly on Gitter in the last few weeks (if you want to read up). As you can see on the v3.0 board and the various v2.9x.y tags, the release of iceoryx classic is just around the corner for quite some time now, but we didn't push it through as the user-experience-able features and improvements are only of minor nature. If you look at the daily clone numbers of iceoryx classic vs. iceoryx2, it is still in a different order of magnitude. Last week iceoryx2 had ~30 daily unique cloners and iceoryx classic had ~400 daily unique cloners. The industries that use iceoryx are typically very slow-moving, and many are bound to C++ at least for the next few years until Rust is more mature and also more devs are able to write Rust fluently.

Once there is a definite answer on how long the iceoryx community will continue to maintain iceoryx classic, I'll let you know. I'm in favour of doing iceoryx classic v3.0 release in 2025 and then run it in a maintenance mode for at least a couple more years.

Regarding your questions I can take two and leave the other two for @elBoberido:

3. What are the critical bugs in Iceoryx (classic)? Is there a publicly available list?

Find the full list here. Probably the most tricky ones are:

1. potential deadlock in roudi Mon+Discover and IPC-msg-process thread #1546
2. Deadlock in shared mem mutex when apps are killed #325

4. In your opinion, is it easy to upgrade from Iceoryx to Iceoryx2, or are they completely different libraries?

I haven't used iceoryx2 much myself. However, the C++ API of iceoryx2 definitely differs from iceoryx classic and I would appreciate any helper to port existing code that uses iceoryx classic to iceoryx2 (e.g. a clang-tidy rule or a custom GPT instance on ChatGPT which automatically rewrites your code).

@elBoberido Do you have planned anything in this direction?

cc @elfenpiff @budrus

[elfenpiff]

@Smiesek

What is the current status of the C++ API in Iceoryx2, and of the library itself?

The library is production-ready in C, C++ and Rust. It is already used in mission-critical systems, such as medical devices, autonomous vehicles, high-frequency trading, and game engines. The reason why it is not yet v1.0 is that not all the features we envision for 1.0 are yet implemented - things like the blackboard pattern, Python language bindings, STL library in Rust and C++, which is memory layout compatible, etc.
But I think the v1.0 release will come latest beginning of next year.

What does "Works with a restricted security and safety feature set" mean in the context of the Linux platform?

Linux has a full security and safety feature set. This applies for instance to Windows or Mac Os, operating systems you do not find in mission critical systems like cars.

What are the critical bugs in Iceoryx? Is there a publicly available list?

The main issue with classic iceoryx is, that the overall design does not allow a deployment in critical systems since the freedom of interference requirement cannot be satisfied. This would require a heavy refactoring and we came to the conclusion that a rewrite of iceoryx in Rust was the better solution.

In your opinion, is it easy to upgrade from Iceoryx to Iceoryx2, or are they completely different libraries?

Actually, it is easy and straightforward. All the concepts are the same. The c++ API of iceoryx2 also has the same base library as classic iceoryx. In the next weeks we also wanted to provide a transition tutorial but the code changes should be minimal.
But as soon as you have switched you gain some huge advantages:

• no more central daemon
• no more compile time configuration (iceoryx2 does this all for you)
• completely dynamic data types
• advanced embedded and safety features (hypervisor support, GPU)
• much faster and memory efficient.
• much more robust due to the decentralized architecture