iceoryx v3.0 release coordination

[elBoberido]

@FerdinandSpitzschnueffler @mossmaurice @dkroenke @MatthiasKillat @budrus @elfenpiff please have a look at https://github.com/eclipse-iceoryx/iceoryx/projects/5 and check if there is something in the To do column which you want to have for the v3.0 release. Except Release validation which should be reduced to the tasks we did for v1.0, I think everything can easily be postponed to v4.0 since contain bugs that are either fixed and just need some confirmation or issues which are also present in v2.0.

Some of the items in the In progress column are also no blocker for a release and the others are basically done and just need a final entry in the release notes.

[mossmaurice]

@elBoberido

check if there is something in the To do column which you want to have for the v3.0 release.

I went over all the issues in the project under "To do" and "progress".

My recommendation and effort estimates:

Must-haves

• Find a name for the release by voting as we did it for the previous releases ☕ 🥕 🍰 🍫
• Release validation for v3.0 #1295, for me the docs are definitely a must-have as otherwise it will be confusing for users and there will be reports like Versions 2.0.4 and 2.0.5 not availble in docs (pages) #2134
  • ~5 days effort, as the build of the docs is currently broken due to the change to relative links
• When I delete the sleep statement of the publisher of the example iceoptions, I find that the subscriber will not receive some messages #1541, could be addressed together with the release validation
  • ~3h effort
• Handle 'strerror_r' idiosyncrasies in the platform layer #1616, sounds like we should address this topic before the v3.0 release
  • ~6h efforts, but rather hard to estimate for me, please double check 🚧

Can be postponed to v4.0

• Improve modularity by creating architecure guidelines #590 ✔️
  • Nearly done, a few @todos still in the code
• Split iceoryx_hoofs into logical modules #1391, not a blocker for the release, just a nice to have ✔️
• Make clearer distinction between public and private API for iceoryx_hoofs #1921, not a blocker for the release, just a nice to have ✔️
• Create a flat include structure for iceoryx_hoofs #1593 was already done ✔️
• Exchangable and customizable iceoryx platform #1432, documentation can be done for the next release ✔️
• ErrorHandling concept with user defined actions #1032, the scope of this issue is a bit unclear to me, I think it can be postponed, please double-check 🚧
• Don't exclude implementations of public classes in Doxygen #1293, just needs some documentation of the approach e.g. in CONTRIBUTING.md, please double-check 🚧
• acl_entry_t leak in posix wrapper AccessController #1646 I don't think this is actually an issue, please double check 🚧

Except Release validation which should be reduced to the tasks we did for v1.0, I think everything can easily be postponed to v4.0 since contain bugs that are either fixed and just need some confirmation or issues which are also present in v2.0.

I agree, besides finding the release name and basic release validation of the docs, most of the issues can be postponed to v4.0

[elBoberido]

• ErrorHandling concept with user defined actions #1032: This is actually done but the issue description does not match the actual work and needs to be updated
• acl_entry_t leak in posix wrapper AccessController #1646: From my point of view this is not a problem. I already looked at it some time ago but I need confirmation from a second developer. This is a non-blocker from my point of view.
• Don't exclude implementations of public classes in Doxygen #1293: We can keep this in v3.0 but handle it as non-blocker
• When I delete the sleep statement of the publisher of the example iceoptions, I find that the subscriber will not receive some messages #1541: This is s a documentation issue and not an actual bug but it should be fixed for v3.0
• Handle 'strerror_r' idiosyncrasies in the platform layer #1616: Indeed, it should not be too hard to fix
• Release validation for v3.0 #1295: This is something we need to cut down to the minimum else the release will be dragged out for months
• Listener addEvent deadlock #2202: This came in recently and should be fixed for v3.0; either a proper fix or at least the documentation needs to state the issue and how to prevent it
• Don't exclude implementations of public classes in Doxygen #1293: Yes, needs some documentation but also not a blocker.
• Improve modularity by creating architecure guidelines #590: Yup, can be postponed
• Make clearer distinction between public and private API for iceoryx_hoofs #1921: This can also be postponed