"
The package name must start with a letter and contain only lowercase alphabetic, numeric or underscore characters. The package name should be unique within the ROS community. It may differ from the folder name into which it is checked out, but that is not recommended.
The following recommended exemptions apply, which are optional for implementations:
Dashes may be permitted in package names. This is to support maintaining a consistent dependency name when transitioning back and forth between a system dependency and in-workspace package, since many rosdep keys contain dashes (inherited from the Debian/Ubuntu name).
In support of some legacy packages, capital letters may also be accepted in the package name, with a validation warning. "
The XSD should reflect this entire section, including the optional bits about allowing dashes and allowing capital letters. If we want to disallow them in some circumstances, then the downstream linters should enforce that.
Because of that, this PR relaxes the XSD for each of the package formats to accept the full range.
Note to reviewers: please carefully check the regular expression. In my local testing this seems to do the correct thing, but we want to make really sure that this is correct before we merge and deploy this.
Each of them has the same note in their corresponding REPs (https://www.ros.org/reps/rep-0127.html#name, https://www.ros.org/reps/rep-0140.html#name, https://www.ros.org/reps/rep-0149.html#name):
" The package name must start with a letter and contain only lowercase alphabetic, numeric or underscore characters. The package name should be unique within the ROS community. It may differ from the folder name into which it is checked out, but that is not recommended.
The following recommended exemptions apply, which are optional for implementations:
The XSD should reflect this entire section, including the optional bits about allowing dashes and allowing capital letters. If we want to disallow them in some circumstances, then the downstream linters should enforce that.
Because of that, this PR relaxes the XSD for each of the package formats to accept the full range.
Note to reviewers: please carefully check the regular expression. In my local testing this seems to do the correct thing, but we want to make really sure that this is correct before we merge and deploy this.