Pending PRs / issues:
Coordinated releases:
I'm waiting for the sync of tf2_eigen on Nov, 27th. Which open issues / PRs (other than #1096) should be merged?
(List is moved to OP https://github.com/ros-planning/moveit/issues/1225#issue-384066739)
Can we always communicate about release in a explicitly designated ticket
Yes please! :confused:
As explained in https://github.com/ros-planning/moveit/pull/1166#issuecomment-441732884 , I would prefer to hold off until end of next week to have time to test changes.
As @davetcoleman already started the release-cycle with rviz-visual-tools, the ROS build farm is breaking:
http://build.ros.org/view/Mbin_uB64/job/Mbin_uB64__moveit_visual_tools__ubuntu_bionic_amd64__binary
For this reason, I suggest to continue with the release process. This way, we have enough soaking time before the next sync. I think, it's better to test those changes in a larger community (of shadow-fixed users) instead of restricting to "from-source builders".
@v4hn @130s @davetcoleman Opinions?
Seems a little rushed to me to make a release since we just did one...
Seems a little rushed to me to make a release since we just did one.
This release comprises many API changes and we should release them as early as possible - before many people have adopted Melodic in a production environment and then would face API changes in the middle of a stable release. I think, we agreed that big API changes like these should be merged (and released) asap before freezing API again (by the end of the year?)
2nd argument is, that the MoveIt jobs on ROS build farm are broken right now:
rviz_visual_tools.3rd argument: The next sync will happen in about two weeks, probably with a freeze a week before again. Hence, waiting for another week, we again risk to run into the freezing phase, which makes it a little harder to merge release requests (needs extra communication).
4th argument: Releasing to shadow-fixed will reach a larger community for testing than relying on from-source-builds.
Finally, I am using my changes in production since several weeks.
These are good arguments, sounds good to me.
bin jobs are broken, because @davetcoleman already triggered the release process by releasing rviz_visual_tools.
Notably, you are the one who asked me to make that release :-)
I would like to the release on the weekend. Any objections?
No objections. Just noticed there are still a few open items in the list https://github.com/ros-planning/moveit/issues/1225#issue-384066739
Please feel free to review them ;-)
If I don't get reviews, I will merge them anyway.
Release triggered: https://github.com/ros/rosdistro/pull/19662
Release build was successful: Melodic build status.
However, as pointed out in https://github.com/ros-planning/moveit/pull/1251#issuecomment-445873674, removing moveit_experimental from the set of released packages, doesn't automatically uninstalls this package. Thus, when updating to 0.10.6, we get a clash:
E: /tmp/apt-dpkg-install-i6AXUC/02-ros-melodic-moveit-core_0.10.6-0bionic.20181210.112240_amd64.deb: trying to overwrite '/opt/ros/melodic/include/moveit/collision_distance_field/collision_common_distance_field.h', which is also in package ros-melodic-moveit-experimental 0.10.5-0bionic.20181117.194840
@clalancette Is there a way to automatically uninstall removed packages?
Alternatively, could we release a new, empty moveit_experimental package, i.e. remove the redundant file(s) by updating moveit_experimental?
@rhaschke This is debian package management. We could in theory add a conflict between current moveit_core and moveit_experimental to force the user to uninstall, but even if bloom supports this it's rather ugly.
I believe the only reasonable way out is to release moveit_experimental once more with the collision_distance_field components gone. It seems stupid to release an empty package, but that's the road we chose when we released moveit_experimental before..
Two guys, one idea... Waiting for feedback from @clalancette.
OK, I will try this approach. Looks like the easiest one.
Yeah, I agree with @v4hn that we should release moveit_experimental as an empty package, that way upgrades will be smooth for users.
Hurray empty debian packages!
Although, upgrading worked in principle, we have still an issue due to the wrong upgrade order (moveit-experimental being upgraded last):
https://hub.docker.com/r/moveit/moveit/builds/bxgqrlckusgbj9ta4a4ktr9
I prepared a new release, defining a (temporary) dependency from moveit-core to moveit-experimental:
https://github.com/ros/rosdistro/pull/19677
Thanks @rhaschke !
Triggered a new release, https://github.com/ros/rosdistro/pull/19714, to fix regression #1259 / #1261.
@clalancette Could you please hold back the upcoming ROS Melodic sync a few more days?
The recent MoveIt release introduced some regressions: https://github.com/ros-planning/moveit/pull/1271, https://github.com/ros-planning/moveit/issues/1255, which I would like to get merged / fixed before.
@rhaschke That's fine, I'm still waiting on the pilz_industrial_motion release before I go into freeze anyway. If that gets done this week, but you still aren't ready, I'll start the freeze with an explicit exception for MoveIt.
Triggered a new release 0.10.8: https://github.com/ros/rosdistro/pull/19825
0.10.8 released and synced.