Anyone interested in a friendly fork?

[traversaro]

Hello everyone, in my organization we are depending on an heavily patched version of serial (mostly for CMake fixes to support FetchContent and lately CMake 4.0), available at https://github.com/ami-iit/serial .

As maintaining the patches is becoming a bit complex and the upstream of wjwwood/serial is not interested in merging changes, I am considering to just rename our fork with a distinct name (to avoid conflicts with existing serial installations) and start maintaining the friendly fork itself (in the sense of tagging releases, not making a lot of development unless we need it).

A possible name to use for this new friendly fork is serial-cpp for the repo name, and serialCpp for include directory and C++ namespace. I plan to do this in the next days, but I tought it was interesting to share this plan here in case there was some similar initiative somewhere that I missed.

[wjwwood]

Feel free to fork, I don't have time to maintain this properly, as was mentioned in other issues. There was a plan to fork it for ros 2 and rename it but that has seemed to stagnate.

I would ask that you do rename it as to avoid confusion with this repo and to pick a better name (serial is too generic in my opinion). Which you are already considering so that's good.

I would suggest you pick a package name that follows the ros conventions if you're planning on releasing it in ros, which means you'd be better off using an _ in the name rather than a -. In fact I would suggest you do that even if you're not planning on releasing it in ros but that's up to you. If you did that then it would also mean that you wouldn't need a different name for the package name and for the include path and cpp namespace, which would be better and more consistent in my opinion.

[traversaro]

Thanks for the feedback! This is a good idea. Indeed our primary goal was not to release in in the ROS buildfarm, but to release (as most software maintained by my organization) in non-domain specific C++ package managers like vcpkg/conan/conda-forge and hence the reason why we typically use - as separators in the repo name (also for consistency with Python repos that follow a similar custom).

However, considering the history of the package I see why using _ could be a good choice. So a possible choice would be serial_cpp for repo name, CMake package name, C++ namespace and C++ include folder, unless that is too similar and could induce confusion.

[wjwwood]

I wouldn't object to serial_cpp.

I had long considered a longer but more specific name for this library as "serial" has overlap with serialization, sequencing algorithms, serial numbers, ros serial (for micro controllers), etc.

It's also true that things like pyserial are just fine despite this generic word (this library was originally inspired by pyserial) but I just have felt since I released it that it was too generic. However with at least serial_cpp it's narrowed it down a bit more and definitely rolls off the tongue more that serial_comm or serial_io or something like that.

[traversaro]

Thanks! I started the fork at https://github.com/ami-iit/serial_cpp . In the next few days I will incorporate the changes that we use, and update the docs/code.

[traversaro]

Ok, the initial migration/rename for (what concern the use of my organization) is completed, and the first release is available at https://github.com/ami-iit/serial_cpp/releases/tag/v1.3.0 . If anyone is interested in having more changes, feel free to open PRs or issue there. I also opened gbionics/serial_cpp#3 in case someone is interested in packaging the library for the ROS 2 buildfarm (I have no plans w.r.t. to that).