proposal: Rotary release repos

[azeey]

Supplemental to #1403

Based on discussion between myself and @scpeters.

Overview

We propose creating {package}-rotary-release repos for each package in a Gazebo collection for the purpose of releasing packages from main branches of each source repo. These release repos will contain debian metadata for unversioned Gazebo packages (e.g. libgz-math-dev) and aliases to these packages with the rotary label (e.g. libgz-rotary-math-dev). packages.apt files in each source repo will use the rotary aliases.

The benefits of this are:

• The rotary version follows a similar pattern as our other versions that use numbers. Our tooling is likely to handle this with little or no modification
• When it is time to branch-off and create versioned release repos, it would be easier to fork the *-rotary-release repos and make changes.

Implementation Steps

Initial implementation

• Remove versions from control files. The packages as well as the Gazebo dependencies will be unversioned.
• Add rotary aliases pointing to the unversioned packages
• Remove versions from rules. This may not be trivial as some commands might need versioned directories for destination paths (e.g. https://github.com/gazebo-release/gz-sim11-release/blob/2277953bdfad71f10c39a1dc18a2833b09e0af2e/ubuntu/debian/rules#L35)
• Make nightly releases from rotary. We'll need to modify ignition_collection.dsl. Simply changing gz_nightly = 'rotary' won't work because the debbuilder names are computed as {package}{major version}-debbuilder.
• Bump main source branches to new major versions
• Update package.apt files use rotary packages

At branch-off

• For each package, fork the {package}-rotary-release repo and modify the control files to include the major version number. See Strategy for major version bumps in new collections #1403 (comment) Phase 3 about deciding which major version to use. We'll need to have a script that automates this process.
• As we create stable branches in source packages, use the same rotary -> versioned package mapping to update packages in packages.apt. -
• Update gz-collection.yaml, gazebodistro and homebrew so that the new (about to be released) collection points to the stable branches and each of the corresponding packages depend on versioned packages (not aliases).

Next release cycle

• No change to {package}-rotary-release repos
• Bump major version numbers in main, but no change in packages.apt
• Follow the same steps from branching off as above.

Alternatives Discussed

Do what we normally do, which is create new release repos with bumped version numbers. Create a gz-rotary-release release repo which will contain aliases to all the versioned packages from main branches (e.g. libgz-rotary-math-dev). These will then be used in packages.apt files in source repos. Downsides of this approach:

• gz-rotary-release will need to be updated every year because it points to versioned packages.

[scpeters]

These release repos will contain debian metadata for unversioned Gazebo packages (e.g. libgz-math-dev) and aliases to these packages with the rotary label (e.g. libgz-rotary-math-dev). packages.apt files in each source repo will use the rotary aliases.

we have a different naming scheme for the package aliases in Jetty (like gz-jetty-math rather than libgz-jetty-math-dev), mainly because it was the first approach taken during implementation and there wasn't enough time to change it before the Jetty release. I'm ok with the libgz-rotary-math-dev approach for rotary, and we can also backport libgz-jetty-* aliases if we want

[scpeters]

Implementation Steps

Initial implementation

...

• Bump main source branches to new major versions
• Update package.apt files use rotary packages

I think these two steps could happen in parallel / either order

[scpeters]

• Remove versions from rules. This may not be trivial as some commands might need versioned directories for destination paths (e.g. https://github.com/gazebo-release/gz-sim11-release/blob/2277953bdfad71f10c39a1dc18a2833b09e0af2e/ubuntu/debian/rules#L35)

I think we can remove these other instances of package version numbers in install paths. I didn't consider these "user-facing" so I didn't prioritize them in my big push for Jetty. If it simplifies things for Rotary, then lets remove them.

[scpeters]

At branch-off

• For each package, fork the {package}-rotary-release repo and modify the control files to include the major version number. See Strategy for major version bumps in new collections #1403 (comment) Phase 3 about deciding which major version to use. We'll need to have a script that automates this process.
• As we create stable branches in source packages, use the same rotary -> versioned package mapping to update packages in packages.apt. -
• Update gz-collection.yaml, gazebodistro and homebrew so that the new (about to be released) collection points to the stable branches and each of the corresponding packages depend on versioned packages (not aliases).

I would add a step here to use explicit versions in the find_package calls using the set_explicit_find_package_versions.bash script from #1430, similar to what was done for jetty in gazebosim/gz-jetty#137

[scpeters]

I made a few comments and am 👍 on the approach

[scpeters]

I tried prototyping the gz-rotary-cmake and gz-rotary-utils debian metadata changes:

• gz-rotary-cmake scpeters/gz-rotary-cmake-release#1
• gz-rotary-utils scpeters/gz-rotary-utils-release#1

I also wrote a quick tool for adding collection-specific aliases: #1449

[scpeters]

I have a prototype of what gz-rotary-* formulae could look like in osrf/homebrew-simulation#3287