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.
, so, let’s wait for an answer from rtabmap to see their opinion (!)