-
Notifications
You must be signed in to change notification settings - Fork 279
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
catkin_prepare_release: needs more flexible tag naming option #447
Comments
With this patch, I can do this and have the tags generated correctly:
|
Just out of curiousity: do you have more than one package in a repo or why do you prefer the additional prefix? |
More than one package: yes. But, it's really the repo name that is used as a tag prefix. As to why: it's mostly a matter of longstanding habit. I believe rosrelease did it that way. Bloom supports that style, but catkin_prepare_release does not. |
With SVN repositories, which do contain multiple collections of packages, it is probably necessary. |
For SVN there no real difference regarding tagging:
|
Maybe it's not necessary, but there still exist older repositories from pre-catkin days using that tag syntax. The rosrelease tool created them. Why are you so reluctant to support it? |
I wrote:
I am not reluctant to support it at all. As soon as the PR is ready it will be merged immediately. I asked these questions only to understand why people want to do that in order to understand their use case better. |
I see. The main reason is that old repositories used a certain tag style, and it's convenient not to have to change it. |
catkin_prepare_release: add --tag-prefix argument (#447)
Can this not be closed? |
I would like to use this tool, but most of my packages use the
package_name-:{version}
rule for release tags.Since
catkin_prepare_release
creates a tag with just the new version number, I have to delete that tag and create the correct one manually. So, I find myself doing the whole thing by hand, rather than take advantage of this useful tool.Adding an appropriate option looks straightforward. I will submit a patch when I get the chance, but will not be able to work on it for at least a couple of weeks. Anyone else is welcome to fix it before then.
The text was updated successfully, but these errors were encountered: