iox-#743 Set all documentation links to v2.0.0

[mossmaurice]

Pre-Review Checklist for the PR Author

1. Code follows the coding style of CONTRIBUTING.md
2. Tests follow the best practice for testing
3. Changelog updated in the unreleased section including API breaking changes
4. Branch follows the naming format (iox-#123-this-is-a-branch)
5. Commits messages are according to this guideline
   • Commit messages have the issue ID (iox-#123 commit text)
   • Commit messages are signed (git commit -s)
   • Commit author matches Eclipse Contributor Agreement (and ECA is signed)
6. Update the PR title
   • Follow the same conventions as for commit messages
   • Link to the relevant issue
7. Relevant issues are linked
8. Add sensible notes for the reviewer
9. All checks have passed (except task-list-completed)
10. Assign PR to reviewer

Notes for Reviewer

• Set all documentation links to v2.0.0

Checklist for the PR Reviewer

• Commits are properly organized and messages are according to the guideline
• Code according to our coding style and naming conventions
• Unit tests have been written for new behavior
  • Each unit test case has a unique UUID
• Public API changes are documented via doxygen
• Copyright owner are updated in the changed files
• PR title describes the changes

Post-review Checklist for the PR Author

1. All open points are addressed and tracked via issues

References

• Closes Improve documentation and website for v2.0 #743 (partly)

[elfenpiff]

Not a single link is working since the tag v2.0.0 does not exist.

The better approach would be that every link points to the release_2.0 branch.

With source code we already have the approach that with every PR everything has to work always. I think we should stick to this strategy also for documentation

[mossmaurice]

Not a single link is working since the tag v2.0.0 does not exist.

The better approach would be that every link points to the release_2.0 branch.

With source code we already have the approach that with every PR everything has to work always. I think we should stick to this strategy also for documentation

@elfenpiff Thanks for review! I don't understand how using the release_2.0 branch can work in practice. We basically have a chicken-egg problems. All the docs need a fixed version, hence release_2.0 is not possible, as there might be v2.x.y coming in later on this branch. However, we have to set this version before we add the Git tag v2.0.0 otherwise the links will already be outdated.

[codecov]

Codecov Report

Merging #1254 (91dd909) into release_2.0 (1f7e86f) will increase coverage by 0.02%.
The diff coverage is n/a.

@@               Coverage Diff               @@
##           release_2.0    #1254      +/-   ##
===============================================
+ Coverage        78.91%   78.94%   +0.02%     
===============================================
  Files              370      370              
  Lines            14706    14706              
  Branches          2059     2059              
===============================================
+ Hits             11605    11609       +4     
+ Misses            2419     2417       -2     
+ Partials           682      680       -2     

Flag	Coverage Δ
unittests	78.15% <ø> (+0.01%)	⬆️
unittests_timing	15.49% <ø> (+0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...nternal/roudi/introspection/port_introspection.inl	82.11% <0.00%> (-0.73%)	⬇️
iceoryx_hoofs/source/posix_wrapper/timer.cpp	63.90% <0.00%> (+0.82%)	⬆️
iceoryx_hoofs/source/concurrent/loffli.cpp	91.42% <0.00%> (+11.42%)	⬆️

[elBoberido]

Could all commits be squashed with a commit message to indicate setting the version to v2.0.0? This makes it easier to drop the commit when the changes from the release branch are merged back to master

[elBoberido]

Since there are more changes than just setting the links to v2.0.0 dropping commits might not be a good idea. Luckily it should be easy to do a mass search and replace.