You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I'm not sure whether this is the right place, so feel free to correct me.
I have several questions related to each other and a problem:
I noticed that the ros2-humble* packages in http://packages.ros.org/ros2/ubuntu/ have their versions in the style: 0.20.5-1jammy.20241128.022958. Why are you including the build number and why isn't the version tag sufficient? Do the packages differ despite the same major.minor.patch version?
It seems your buildserver regularly updates the apt repository with new versions. The previous build is then deleted. This makes it impossible to checkout the same specific version of a package as it will disappear, as soon as a new package is published (that might be the same, see 1.)
Even at the same time point of checkout, the version tags between amd64 and e.g. arm64 differ by the buildnumber. I can imagine why. But this make it unclear whether the two architectures are operating on the same code.
I'd be happy if you could elaborate, why you are not simply using the simple version tag e.g. 0.20.5-1
Thanks already, I'm looking forward to your answers!
The text was updated successfully, but these errors were encountered:
This all really tracks back to the enforcement of ABI compatibility:
With something like the Ubuntu upstream packages, they strictly enforce ABI compatibility - so when you release a new version of package you only have to rebuild that one package (everything that depends on it, will still work, since the ABI is the same).
The core of ROS enforces ABI compatibility - but that isn't the case for many of the downstream packages.
Since ABI isn't guaranteed for everything on the build farm, when a new version of something is released, we need to rebuild that package AND every dependency of the package.
The dependencies don't have a new version (in this case 0.20.5-1 hasn't changed - nobody re-ran bloom for this dependent package), but the newly built version needs to be distinguished - and that has traditionally been using the build date (since we know that will increase each time, ensuring that Ubuntu sees the rebuilt package as "newer" than the old one).
Since the version is the "build time" - the arm/amd builds happen in different jobs and thus at different times.
Hi,
I'm not sure whether this is the right place, so feel free to correct me.
I have several questions related to each other and a problem:
0.20.5-1jammy.20241128.022958
. Why are you including the build number and why isn't the version tag sufficient? Do the packages differ despite the same major.minor.patch version?I'd be happy if you could elaborate, why you are not simply using the simple version tag e.g.
0.20.5-1
Thanks already, I'm looking forward to your answers!
The text was updated successfully, but these errors were encountered: