-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add design docs for versioning export #511
base: rolling
Are you sure you want to change the base?
Conversation
Signed-off-by: Ryan Friedman <[email protected]>
Hi, thanks for bringing this up. I have a few thoughts. Regarding declaration of version compatibility of an installed package: This seems like a great feature. While the implementation in
While I don't believe we can use the existing All this said, it is very common for a package to be compatible with more than one major version of a dependency, even under proper use of semantic versioning. This leads to an important question: how do we handle a conflict between what version compatibility is explicitly specified in a downstream package and what downstream compatibility a package expresses in an upstream package? Regarding specification of version requirement of a dependency: This one makes a lot of sense to me, but is largely not a problem in the ROS package ecosystem due to the inherent assumption of ABI incompatibility. At least in the deb and RPM system packages, a package simply isn't available if it didn't successfully build, as would be the case if a package declared a build-time version requirement that wasn't satisfied. That said, there's certainly an argument here to "do the correct thing" especially in the context of other build systems and deployments of ROS 2. I'll also say that implementing this behavior doesn't look trivial at first glance. |
Thanks for the ideas. Here's some follow up questions:
That's a hard question; yea - ABI only breaks if you call the functions that changed ABI. That's why I suggested defaulting to
Sounds like it might be useful to just try a simple prototype of "doing the right thing" and see if blows up. That's generally how I approach these sort of things, but that's more on my lack of experience. If you suspect it's going to be difficult and complicated, I'm happy to split the scope of this effort into two, and focus on the first part which seems more achievable. |
Hello, I'm still interested in this capability. My team has grown significantly and we are breaking ABI frequently in a SDK that's distributed across multiple teams. Different packages have different ABI promises depending on if they are internal use or shared across teams. Would you be ok if I implement this purely as an opt-in feature for the Regarding I propose making upstream decide this, which is how CMake currently works from what I can surmise. If Upstream says |
This adds design docs for how ament packages can express their versioning, and versions of the dependents. It should give nice behavior when making ABI breaking changes if you use Semver.
Please provide feedback. The design docs here explain how it could work. This may require some prototyping to prove it can work.
Copied sections from #506. Read that ticket to get context around the use case and why this is desirable.