agree, that is a really basic policy. THAT GUARANTEES WE DO NOT BREAK THE USERSPACE.
As Karsten said above, the plan was not to break the command line usage and I have asked again here to list the APIs/ABIs that would break with this proposal.
Secondly please read my reply above Fast Forward Merging rosbag2 master API to Foxy - #9 by Dejan_Pangercic. rosbag2 as of today can not be used. Many users have moved on to create their own solutions for record and replay or used rosbag - how is this better than breaking the API/ABI and to help the users to update?
if data corruption or security issue to be addressed, we end up changing those (as less as possible), but not for a feature.
This proposal is not about the new features but about the improvements. The improvements necessitated the change of APIs/ABIs.
That is exactly why we came up with leveldb
where we are standing is,
- rosbag2 / sqlite3 backend is not really fast enough for some use cases.
Lets please not add to the scope of of this post. leveldb does not solve all of the issues that the rosbag2 had, especially on the transport level. Also please note that Robotec.AI’s report concludes that the sqlite3 performance is now actually slightly better than leveldb.
above is my opinion. once we release the public API, i think there is no way to know who uses or relies on that if we think about application as open source perspective.
All of this can be solved easily in my POV with a brief and concise porting guide, which @karsten @emersonknapp I think that we should provide if this proposal will be accepted.
btw, i’d like to know if this kind of discussion about breaking API/ABI in release happened before?
Are you asking if this ever happened in the ROS world before or in rosbag2? The answer to the latter is certainly no and I vaguely recall rare situations from the former (e.g. indigo ABI break in roscpp after update? - ROS Answers: Open Source Q&A Forum).