Skip to content
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 version to docker-images #82

Closed
domire8 opened this issue Mar 27, 2023 · 9 comments · Fixed by #104
Closed

Add version to docker-images #82

domire8 opened this issue Mar 27, 2023 · 9 comments · Fixed by #104
Assignees

Comments

@domire8
Copy link
Member

domire8 commented Mar 27, 2023

As title suggests. Best option would be a workflow that updates the version on push to main.

@domire8 domire8 self-assigned this Mar 27, 2023
@LouisBrunner LouisBrunner self-assigned this May 4, 2023
@domire8
Copy link
Member Author

domire8 commented Sep 11, 2023

comment from @eeberhard

As a side note, how do you feel about tagging the ros2-control image with the version (for example, as :iron and :iron-3.18)? That way if we keep iron but upgrade ros2_control to some other version later, we can distinguish them. Not in scope for this PR but goes in a similar direction and I think would be useful to do.

comment from @LouisBrunner

I think we should just make our own version for this. e.g. v2.3.0+iron

comment from me:

Fair suggestion, do we take the version from a VERSION file?

@LouisBrunner
Copy link
Contributor

I don't mind where we get the version at the moment, as long as we produce 2 tags (v2.3.0+iron and v2.3.0, as it makes package management easier later). I don't mind which of these tags is the ones that makes it into git either.

@domire8
Copy link
Member Author

domire8 commented Sep 11, 2023

But then how we deal with v2.3.1+iron and v2.3.1+humble? I guess that wouldnt be possible anymore? Or humble has major 1 where iron has major 2?

@LouisBrunner
Copy link
Contributor

Iron and humble would be different versions, e.g. v1.4.5+humble and v2.3.1+iron. There is no reason for them to be linked (after all they aren't necessarily compatible).

@domire8
Copy link
Member Author

domire8 commented Apr 23, 2024

A couple of weeks ago, we decided that in the near future, we'll drop the ros2-control image and only ship one ros2-ws image that contains all dependencies we need for ROS2 and ROS2 Control. @LouisBrunner What would be your suggestion for the tags of the image? vX.Y.Z+ROS_DISTRO? I think we could already start to set that up.

@LouisBrunner
Copy link
Contributor

So the new ros2-ws will be equivalent to the old ros2-control?

Yeah I think a version like that makes sense.

@domire8
Copy link
Member Author

domire8 commented Apr 23, 2024

Name is not 100% sure but yeah essentially that's it.

@domire8
Copy link
Member Author

domire8 commented Apr 23, 2024

The + is not allowed in docker images tags though it seems

@LouisBrunner
Copy link
Contributor

Ah, that's a shame. I guess we can do multi-tags and include vX.Y.Z, vX.Y.Z-ROS_DISTRO and ROS_DISTRO and that should be both standard Docker and mostly semver-compliant.

@domire8 domire8 linked a pull request Apr 30, 2024 that will close this issue
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants