It’s been two years since the first release of GTSAM as an official ROS package, and we finally have a new release upstream (v4.3 alpha) with tons of exciting features, including the replacement of Boost with C++17 machinery.
However, this is an API breaking upgrade. Users will need to adapt their code.
So, before jumping and just making a new release of the gtsam ROS package, I would like to check with the community which option would you deem more appropriate:
Just make a new release to the same gtsam package, so for the next release cycle builds will break if users don’t adapt. I also think this should happen for all active ROS distributions (maybe rolling first, some time later backport to the rest).
Create a new package, e.g gtsam4.3, gtsam_no_boost, or alike and leave the old version die with the EOL of current distributions.
I think (1) is better, but didn’t want to make that breaking change without asking the users first…
By coincidence, I was recently checking which packages depend on gtsam ROS package. The answer is 2: rtabmap and mola. Nothing more at the moment, at least among released packages ( ROS Package: gtsam ).
@rkent might help with finding unreleased packages on github, as he recently tried to make some index of unreleased Github packages.
A follow up question: at present, removing Boost as a dependency for GTSAM prevents the usage of serialization. I’m not sure it’s being used a lot, but again, I would like to open the discussion here (and in this PR) before doing anything.
I would release the new version into rolling, and not backport it. It would break existing users. Then when a new L ROS version is released, users will have to start migrating to it. You could even consider backporting it to kilted because its so new, but definately not jazzy.
I think there are more users than mola and rtabmap, I for example have a private package which depends on gtsam.
Just a minor curiosity. In the past, gtsam final release were marked upstream as 4.2, and released in ROS as 4.2.0 . Now that the 4.3a0 release was released in ROS as 4.3.0, is there any plan on which version number will be used by the 4.3 final release?
@traversaro
Good point… As the maintainer of the ROS packaging part of gtsam, I don’t have any better idea than keep publishing all "alpha"s versions of 4.3 as “4.3.0”, with incremental “4.3.0-X” Debian package versions… Incrementing the patch version (4.3.1,…) would collide with future releases upstream.
Update: GTSAM 4.3-a1 has been released upstream, and has been released to ROS2 Kilted and Rolling as an updated “v4.3.0”. It should fix the, now broken, arm64 builds.
, so, let’s wait for an answer from rtabmap to see their opinion (!)
