Can't access older versions (3.1) of ros-humble-isaac-ros-* packages on apt

[ryank-cobot]

Hello,

It seems like with the new Isaac Ros 3.2 release, I am unable to access the the v3.1.0 packages on apt. Please advise on how to access the older versions as we are unable to upgrade to Jetpack 6.1 at this time. Thanks for the help in advance!

[ryan]:~/ $ apt-cache policy ros-humble-isaac-ros-common
ros-humble-isaac-ros-common:
  Installed: (none)
  Candidate: 3.2.0-0jammy
  Version table:
     3.2.0-0jammy 500
        500 https://isaac.download.nvidia.com/isaac-ros/release-3 jammy/release-3.0 arm64 Packages

[jaiveersinghNV]

Hi @ryank-cobot ,

We have relocated the Debians produced for the previous Isaac ROS 3.1 release under the apt component legacy-release-3.1. The release-3.1 version of our documentation has been updated with the version-specific instructions:
https://nvidia-isaac-ros.github.io/v/release-3.1/getting_started/isaac_apt_repository.html#setup-source

Additionally, the source code for those packages will continue to live on the release-3.1 branches of our GitHub repositories.

Let us know if you need anything else.

[ryank-cobot]

Hi @jaiveersinghNV thanks so much for the response. I was unable to find the correct version of the documentation originally so that was the issue. I will try this and update if there are any further issues. Thanks again.

[tomasz-lewicki]

Hi @jaiveersinghNV,

Would you consider not doing that? (i.e. not renaming the apt component after a version goes legacy). Here's my perspective from dev experience standpoint:

It’s confusing when an apt component disappears or is renamed mid-development. I'd rather learn about a new isaac_ros release from a newsletter, than my cli command failing 😅 Also, apt-get cli is often part of CI pipelines, or docker builds. Unexpected changes can disrupt these, and usually take a while to debug.

Coupling version numbers to components seems a bit odd in general, and I typically see them used in a slightly different way across releases: https://wiki.debian.org/DebianRepository/Format#Components.

Lastly, we work with robots, and it takes time to ship a system. Often spanning over multiple Isaac ROS releases. Once shipped, these systems need long-term maintenance. In some cases, we need to provision older-generation robots in the field. All of the above are cases in which it can potentially save hours of debugging the legacy codebase to have the old docker images still work in a reproducible way.

Open to suggestions, and please let me know if there's a better workflow I can adopt on my side!

[jaiveersinghNV]

Hi @tomasz-lewicki ,

Thank you for your feedback - I hear you loud and clear. I am working with the team to bring our Debian update process in line with best practices.

We use our own software on our own robots, too, so the need for stable long-term versioning is well understood on our side. Our goal with the versioned Debian components is to offer customers an obvious way to lock their Isaac ROS installation to a particular major or minor release. While it's true that we could ship all of our Debian packages in a single component, this would require users to set their own apt preferences to achieve similar version control; we believe our multi-component approach is simpler.

We'll share more about our long-term version support in a future release.

[tomasz-lewicki]

@jaiveersinghNV, thanks for the quick response. Understood about the rationale about using components this way. In that case, I believe a simple change of:

1. Renaming release-3.0 to latest
2. Keeping specific releases at components named release-3.1, release-3.0, etc.

would:

1. Bring a big improvement in clarity (latest seems to reflect the current state of things better than release-3.0)
2. At the same time support the original intention of offering the customer ability to lock to a particular release for a long time
3. Keep the multi-component approach that avoids dealing with apt preferences.