Iox2 1351 package version api

[ComicSansMS]

Notes for Reviewer

Pre-Review Checklist for the PR Author

• Add sensible notes for the reviewer
• PR title is short, expressive and meaningful
• Consider switching the PR to a draft (Convert to draft)
  • as draft PR, the CI will be skipped for pushes
• Relevant issues are linked in the References section
• Branch follows the naming format (iox2-123-introduce-posix-ipc-example)
• Commits messages are according to this guideline
  • Commit messages have the issue ID ([#123] Add posix ipc example)
  • Keep in mind to use the same email that was used to sign the Eclipse Contributor Agreement
• Tests follow the best practice for testing
• Changelog updated in the unreleased section including API breaking changes
• Assign PR to reviewer
• All checks have passed (except task-list-completed)

PR Reviewer Reminders

• Commits are properly organized and messages are according to the guideline
• Unit tests have been written for new behavior
• Public API is documented
• PR title describes the changes

References

Closes #

[elBoberido]

Food for thought. In iceoryx classic, we generated a C header from the version set in cmake. See also -> https://github.com/eclipse-iceoryx/iceoryx/blob/main/iceoryx_platform/cmake/iceoryx_versions.h.in

This gave us the option to use the version info for deprecation macros like this -> https://github.com/eclipse-iceoryx/iceoryx/blob/main/iceoryx_hoofs/legacy/include/iceoryx_hoofs/cxx/optional.hpp#L22

It's on my todo list to also introduce this macros for iceoryx2 once we reached 1.0, in order to provide a smoother migration path if we deprecate an API call. So, having an analogous C header would help.

[elfenpiff]

I want to provide a little background on the package version. It is currently stored in the first 8 bytes of any shared memory object iceoryx2 creates. When a user wants to connect to anything within iceoryx2, the package version is verified first, and only if it matches does the connection proceed.

The only construct lacking this is static service details (based on the static storage concept).

The question is, if we ever change the layout/implementation of the rust package version and if a C++/C/Python user might want to acquire the package version of a running iceoryx2 instance. If so, it would make sense to create a "classical" C binding for it and have just one implementation as the source of truth.

If this is a non-existing use case, this approach is fine. We can always provide CLI tooling to perform this task.

[elfenpiff]

For testing we can add a c++ header file called testing.hpp with a testing name space and add a friend function that is able to instantiate different package versions to test the operators.

[elfenpiff]

Could you please rename the file to package_version.hpp. Currently, the file name and the class name correspond - nearly everywhere. I would try to keep it consistent. Same goes for package_version.cpp

[elfenpiff]

Why make it a struct with public accessible members?

I think this shouldn't be a generic building block that the user can use in their project to define their package version, but it is more the current package version of the iceoryx2 crate and in this case, the user should never change the version.

So I would turn it into a class and add 3 getter methods major(), minor() and patch(). This also reduces the API surface a bit.