Schema versioning strategy

[scpeters]

Context

I had a discussion with @clalancette and @sloretz about this and am sharing some of the contents here:

1. The URDF specification has become broadly used beyond even the ROS community. There are many URDFs in circulation, and we should preserve backwards compatibility such that any URDFs that work today will always continue to work.

2. As new features are added to the URDF specification, we suggest incrementing the existing version tag documenting feature support within versions to avoid confusion about which URDF files can be used with which version of ROS. The default value of this version tag is currently 1.0, and the parser throws a runtime_error exception if any other version is parsed.

Recent issue with Quaternion support

The schema version should be incremented when adding new features. I noticed a bit late that support for quaternions was merged in #194 and tagged in 5.0.3. I think before the version goes into widespread use that we should increment the schema version (perhaps to 1.1), so that URDFs must declare version 1.1 in order to use the new quat_xyzw attribute. Likewise, we would also need to update the version check logic in model.cpp's parseURDF function. Perhaps add a maximum supported URDF spec version and throw the exception if the version to be parsed exceeds that.

cc @ahcorde

[scpeters]

Additionally, we should document the new schema version so that users know which URDF version is required in order to use the quaternion feature

[saikishor]

Hello!

I totally agree that this should go under the versioning and things should be handled at the library level. We should also discuss the strategy level about versioning, like we version all the new/breaking changes by bumping the version number or should we bump it for each and every breaking change we have in future.

[saikishor]

Hello!

I totally agree that this should go under the versioning and things should be handled at the library level. We should also discuss the strategy level about versioning, like we version all the new/breaking changes by bumping the version number or should we bump it for each and every breaking change we have in future.

[scpeters]

Since #194 has already been merged and tagged in 5.0.3, I'm going to open a pull request to revert that PR with the plan of making an additional 5.0.4 tag while we resolve these versioning issues

[scpeters]

Since #194 has already been merged and tagged in 5.0.3, I'm going to open a pull request to revert that PR with the plan of making an additional 5.0.4 tag while we resolve these versioning issues

I just merged #234, which bumped versions to 5.0.4 and then made the 5.0.4 tag

[scpeters]

I opened a draft PR #235 with some of the changes I think are needed to properly support schema versions. I noticed a version number discrepancy with urdfdom_headers as well, so we'll probably want to apply either #232 or #233 to that repository as well

[scpeters]

I opened a draft PR #235 with some of the changes I think are needed to properly support schema versions. I noticed a version number discrepancy with urdfdom_headers as well, so we'll probably want to apply either #232 or #233 to that repository as well

we merged #236 to fix the version sync issue in urdfdom and I've opened ros/urdfdom_headers#92 to fix urdfdom_headers as well. Once that is merged in urdfdom_headers, I'll make a new release tag there so that we can properly find the necessary version

[scpeters]

I just tagged urdfdom_headers 2.0.2, though I haven't made a bloom release

[scpeters]

I opened a draft PR #235 with some of the changes I think are needed to properly support schema versions. I noticed a version number discrepancy with urdfdom_headers as well, so we'll probably want to apply either #232 or #233 to that repository as well

I've marked #235 ready for review

CI fails since the required version of urdfdom_headers is not available