We are releasing an initial version of the ros2-exporter-agent prior to issuing an actual proper release. To avoid breaking existing setups, we want to use the 0 track until then.
This request is on the behalf of the Robotics team.
Thanks!
We are releasing an initial version of the ros2-exporter-agent prior to issuing an actual proper release. To avoid breaking existing setups, we want to use the 0 track until then.
This request is on the behalf of the Robotics team.
Thanks!
Hi,
Per Process for aliases, auto-connections and tracks, we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days. I have three questions before casting my vote.
What’s the package’s release cadence, how often is a new major version (potentially requiring a new track) released? Is this documented somewhere by upstream?
Is there some commitment from upstream on maintenance of old versions? e.g. is the “0.1” release still supported with security updates? Will it continue to be supported now that e.g. “0.2” is out, and for how long?
Are new versions backwards-incompatible? Meaning, if I was running “0.1” and try to install “0.2”, will that just work, or do I need to migrate my data/configuration, or will things break horribly?
Thanks,
Siva.
Hi @kodoroki ,
We are currently establishing the whole release process for the entire stack (note that this snap is only part of a larger system). At the moment we have settled on following the COS release cadence that itself follows the Ubuntu release cadence we a new ‘version’ - a new track - every cycle. Eventually tracks will be supported for 9 months and LTS tracks for 10 years. New versions (tracks) are assumed non-backward compatible and migration mechanisms will be put in place between LTSes if necessary. This is all documented in a spec.