The site is read-only. Please transition to use Robotics Stack Exchange
| ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
 | 1 | initial version |
There is no automated way to migrate patches from one distro release to the next, it is ticketed here:
https://github.com/ros-infrastructure/bloom/issues/116
Release numbers have no bearing on what patches are applied. That number simply gets incremented each time you run bloom, such that you can (re) release a track without any patches and the release increment number will be automatically incremented.
You should not manually set the release increment number and doing will not accomplish anything.
Only the *.patch files in the patch/* branches might be portable to another branch. The patches.conf and other non-*.patch files are not portable because they are used by bloom for storing state of specific branches.
This is the strategy I would use:
First clean up your release repo:
The above is optional, but it would be nice to clear them out, if you pushed to github (btw never do this until you are satisfied with the results) then you will need to remove the tags and branches from github as well (if you don't bloom will pull them down and use them).
Next I would:
release/groovy/libfreenectpatches/ branch for the branch to copy from, e.g. patches/release/groovy/libfreenect*.patch files somewhere temporary, e.g. /tmp/libfreenect/patchesgit am /tmp/libfreenect/patches/*.patch (some of these might not merge if your groovy and hydro upstream versions do not match)git-bloom-patch export, this is not required, but it just ensures that the patches you just put on this branch get exported to the corresponding patches branch for this branch.git-bloom-release hydro one more time (this ensures that the new patches you just copied over are used in branches and tags downstream of this branch)That should get you going, but in the future there will be a command help automate this process.
| | 2 | No.2 Revision |
There is no automated way to migrate patches from one distro release to the next, it is ticketed here:
https://github.com/ros-infrastructure/bloom/issues/116
Release numbers have no bearing on what patches are applied. That number simply gets incremented each time you run bloom, such that you can (re) release a track without any patches and the release increment number will be automatically incremented.
You should not manually set the release increment number and doing will not accomplish anything.
Only the *.patch files in the patch/* branches might be portable to another branch. The patches.conf and other non-*.patch files are not portable because they are used by bloom for storing state of specific branches.
This is the strategy I would use:
First clean up your release repo:
The above is optional, but it would be nice to clear them out, if you pushed to github (btw never do this until you are satisfied with the results) then you will need to remove the tags and branches from github as well (if you don't bloom will pull them down and use them).
Next I would:
release/groovy/libfreenectgit-bloom-patch export, this ensures that the patches made here are exported to the corresponding patches/ branchpatches/ branch for the branch to copy from, e.g. patches/release/groovy/libfreenect*.patch files somewhere temporary, e.g. /tmp/libfreenect/patchesgit am /tmp/libfreenect/patches/*.patch (some of these might not merge if your groovy and hydro upstream versions do not match)git-bloom-patch export, this is not required, but it just ensures that the patches you just put on this branch get exported to the corresponding patches branch for this branch.git-bloom-release hydro one more time (this ensures that the new patches you just copied over are used in branches and tags downstream of this branch)That should get you going, but in the future there will be a command help automate this process.
| | 3 | No.3 Revision |
There is no automated way to migrate patches from one distro release to the next, it is ticketed here:
https://github.com/ros-infrastructure/bloom/issues/116
Release numbers have no bearing on what patches are applied. That number simply gets incremented each time you run bloom, such that you can (re) release a track without any patches and the release increment number will be automatically incremented.
You should not manually set the release increment number and doing so will not accomplish anything.change anything but the number which comes after the upstream version.
Only the *.patch files in the patch/* branches might be portable to another branch. The patches.conf and other non-*.patch files are not portable because they are used by bloom for storing state of specific branches.
This is the strategy I would use:
First clean up your release repo:
The above is optional, but it would be nice to clear them out, if you pushed to github (btw never do this until you are satisfied with the results) then you will need to remove the tags and branches from github as well (if you don't bloom will pull them down and use them).
Next I would:
release/groovy/libfreenectgit-bloom-patch export, this ensures that the patches made here are exported to the corresponding patches/ branchpatches/ branch for the branch to copy from, e.g. patches/release/groovy/libfreenect*.patch files somewhere temporary, e.g. /tmp/libfreenect/patchesgit am /tmp/libfreenect/patches/*.patch (some of these might not merge if your groovy and hydro upstream versions do not match)git-bloom-patch export, this is not required, but it just ensures that the patches you just put on this branch get exported to the corresponding patchespatches/git-bloom-release hydro one more time (this ensures that the new patches you just copied over are used in branches and tags downstream of this branch)That should get you going, but in the future there will be a command help automate this process.
| | 4 | No.4 Revision |
There is no automated way to migrate patches from one distro release to the next, it is ticketed here:
https://github.com/ros-infrastructure/bloom/issues/116
Release numbers have no bearing on what patches are applied. That number simply gets incremented each time you run bloom, such that you can (re) release a track without any patches and the release increment number will be automatically incremented.
You should not manually set the release increment number and doing so will not change anything but the number which comes after the upstream version.
Only the *.patch files in the patch/* branches might be portable to another branch. The patches.conf and other non-*.patch files are not portable because they are used by bloom for storing state of specific branches.
This is the strategy I would use:
First clean up your release repo:
The above is optional, but it would be nice to clear them out, if you pushed to github (btw never do this until you are satisfied with the results) then you will need to remove the tags and branches from github as well (if you don't bloom will pull them down and use them).
Next I would:
release/groovy/libfreenectgit-bloom-patch export, this ensures that the patches made here are exported to the corresponding patches/ branchpatches/ branch for the branch to copy from, e.g. patches/release/groovy/libfreenect*.patch files somewhere temporary, e.g. /tmp/libfreenect/patchesrelease/hydro/libfreenectgit am /tmp/libfreenect/patches/*.patch (some of these might not merge if your groovy and hydro upstream versions do not match)git-bloom-patch export, this is not required, but it just ensures that the patches you just put on this branch get exported to the corresponding patches/ branch for this branch.git-bloom-release hydro one more time (this ensures that the new patches you just copied over are used in branches and tags downstream of this branch)That should get you going, but in the future there will be a command help automate this process.
ROS Answers is licensed under Creative Commons Attribution 3.0 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.