Add versioning

[Oberacda]

To make backward compatibility more obvious, we established a versioning system similar to semantic versioning (MAJOR.MINOR.PATCH). Due to the obvious conflict that will arise between ROS 1 and 2, we are making a small shift to ROSVERSION.MAJOR.MINOR with a minor cap at 10 (x.x.10 would instead be x.x+1.0). Version 1.0.0 will be the current main before capabilities are introduced. Dev syncs will normally increase the MINOR, but larger features like capabilities will directly increase the MAJOR. Version 2.0.0 will be the first stable ROS 2 release (this is TBD) and will follow the same pattern afterwards.

[nspielbau]

I think we should change this to the "normal" semantic versioning now that we actually have separate repositories for the different ROS versions

[Oberacda]

OK, would you suggest restarting at release version 0/1 instead of using the ROSVERSION as the release version? If so, we should add a commit as part of the milestone to set this up. This should also be reflected in the version of the documentation on GitHub Pages.

[nspielbau]

Exactly, I would suggest we restart and are currently on 0.1.0, capabilities could mark 1.0.0, but we can discuss that. This has the benefit that we can use the standards set by semantic versioning: MAJOR version when you make incompatible API changes MINOR version when you add functionality in a backward compatible manner PATCH version when you make backward compatible bug fixes One problem with this approach is that we don't have comparability between the ROS 1 and ROS 2 versions, but I think that should be fine as they will diverge in functionality anyways

[nspielbau]

• [x] Add version tag 0.1.0
• [x] Add Changelog.md file

[nspielbau]

@Oberacda I think we can close this