Remove major version from package name

[scpeters]

🎉 New feature

Part of gazebo-tooling/release-tools#1244.

Summary

This removes the major version from the package name in the following places:

• cmake project name and corresponding find_package calls in examples and tutorials
• package.xml name
• python module name and corresponding import statements in tests, examples, and tutorials

Test it

Checklist

• Signed all commits for DCO
• Added tests
• Added example and/or tutorial
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

[scpeters]

@osrf-jenkins run tests please

[scpeters]

I saw what looked like a flaky test, confirmed that it flakes locally, reported it in #2727, and restarted the job with the test failure

[scpeters]

I think gazebo-tooling/release-tools#1246 would fix the windows CI

[scpeters]

gazebo-tooling/release-tools#1246 didn't fix the windows build:

https://build.osrfoundation.org/job/gz_sim-pr-clowin/297/

I'll try something else

[scpeters]

@osrf-jenkins run tests please

[scpeters]

I manually configured the most recent job to run with gazebo-tooling/release-tools#1287 and it passed

https://build.osrfoundation.org/job/gz_sim-pr-clowin/299/

[j-rivero]

Works ! I mean I can run gz sim in the usual way.

Not sure if it is under the scope of this first round of changes but we are still using the version in:

./include/gz/sim10
./libexec/gz/sim10
./share/gz/sim10.yaml
./share/gz/gz2.completion.d/sim10.bash_completion.sh

The point for any all these is if we want to keep the version in the paths.

• For includes/ : given our installation path we could potentially conserve this layout. It would be a weird layout for a software not expecting the parallel installations but would work.
• For libexec/ : similar to includes/
• The .yaml gz configuration: unsure about this one
• The bash completion: seems to go in sync with the yaml gz configuration.

[scpeters]

Not sure if it is under the scope of this first round of changes but we are still using the version in:

./include/gz/sim10
./libexec/gz/sim10
./share/gz/sim10.yaml
./share/gz/gz2.completion.d/sim10.bash_completion.sh

The point for any all these is if we want to keep the version in the paths.

• For includes/ : given our installation path we could potentially conserve this layout. It would be a weird layout for a software not expecting the parallel installations but would work.
• For libexec/ : similar to includes/
• The .yaml gz configuration: unsure about this one
• The bash completion: seems to go in sync with the yaml gz configuration.

these changes are not directly user-facing for developers building with cmake (as opposed to writing compiler flags directly), so I skipped them

we could choose to address them, but would likely need to update the debian metadata

[j-rivero]

these changes are not directly user-facing for developers building with cmake (as opposed to writing compiler flags directly), so I skipped them

we could choose to address them, but would likely need to update the debian metadata

+1

[scpeters]

Not sure if it is under the scope of this first round of changes but we are still using the version in:

./include/gz/sim10
./libexec/gz/sim10
./share/gz/sim10.yaml
./share/gz/gz2.completion.d/sim10.bash_completion.sh

The point for any all these is if we want to keep the version in the paths.

• For includes/ : given our installation path we could potentially conserve this layout. It would be a weird layout for a software not expecting the parallel installations but would work.
• For libexec/ : similar to includes/
• The .yaml gz configuration: unsure about this one
• The bash completion: seems to go in sync with the yaml gz configuration.

these changes are not directly user-facing for developers building with cmake (as opposed to writing compiler flags directly), so I skipped them

we could choose to address them, but would likely need to update the debian metadata

one other point is that at least some of this (maybe all) is configured in gz-cmake

for example the include/gz/sim10 paths are specified in the following files:

• https://github.com/gazebosim/gz-cmake/blob/3509305eadb60b9fc78e91595d9adafa18d525fc/cmake/GzInstallAllHeaders.cmake#L138-L147
• https://github.com/gazebosim/gz-cmake/blob/3509305eadb60b9fc78e91595d9adafa18d525fc/cmake/GzPackaging.cmake#L107-L108

[j-rivero]

There seems to be problem with the Model API on cli on Brew. If these are known or not related, I think we are good to merge.

[scpeters]

There seems to be problem with the Model API on cli on Brew. If these are known or not related, I think we are good to merge.

it only happens on certain CI machines; I think it is unrelated to this change, so I have already merged

[scpeters]

nightly build failed; I'll take a look at fixing the debian metadata:

• https://build.osrfoundation.org/job/gz-sim10-debbuilder/139/

[scpeters]

nightly build failed; I'll take a look at fixing the debian metadata:

• https://build.osrfoundation.org/job/gz-sim10-debbuilder/139/

fixes for debian metadata in the following PRs:

• Remove version number from some install rules gazebo-release/gz-sim10-release#5
• gz-sim-cli: install executable in libexec gazebo-release/gz-sim10-release#6
• Don't install vendored backward files #2838