The question / answer is not specific to colcon but applies to all Python packages, e.g. catkin_pkg, rosdistro, rosdep, bloom, etc.
What version ... should I generally be using? The versions on apt? The versions on PyPI?
On platforms which provide binary packages through the native package manager (on Ubuntu apt) you should use those. Only on platforms which don't have binary packages you should fall back to pip.
Is ... expected to be backwards compatible with all past ROS versions or do I need to do something special to make sure to get ... for, e.g. Dashing?
Generally each tool is compatible with all the distros it is being released into. If for whatever reason a Python package doesn't support an older distro then it is usually also not released for that platform anymore (in the case of binary packages). When installing them via pip such a constraint can't be implemented so if you are using an older distro you might need t double check that the latest version installed via pip is still compatible. Usually that is the case but I wouldn't guarantee that for already EOLed distros.
Is ... expected to be forwards compatible with future ROS versions, e.g. H-Turtle?
All Python package aim for being stable and not break API / behavior in the future. But for obvious reasons that can't be guaranteed since it is unknown what might happen / change in the future.
How can I install a historical version of Colcon together with compatibly-versioned dependencies? e.g. colcon-core==0.4.5 with compatible versions of, e.g. colcon-cmake.
The ROS apt repositories don't provide more than one version of a package so they will only contain the latest version. (That could be different per platform: e.g. Ubuntu Xenial could have a different version than Ubuntu Focal.)
Commonly Python packages don't pin exact versions of their dependencies. Simply because that would make it either impossible to get a new patch release of a dependency if all downstream packages pinned the previous version or would require all downstream packages to bump their pinned version of their dependency and rerelease.
I don't think there is a good way to achieve this (in the Python ecosystem). You could:
- either collect all version numbers on a given date and assume that they will work well together
- or pick a specific version (of e.g.
colcon-core) and then install the latest version of packages which depend on it but don't declare a higher minimum version. (If the minimum version is specified correctly in all packages that should also result in a working set of packages.)
