No proper release versioning or tags [closed]

[jTinkerTs]

I want to create a package (snapshot) of this repository for use in the company I work for. However, there are no release versions or tags to reference when I take a snapshot of the repo. This makes it significantly harder to ensure the differences between our snapshot and the current status of the repository. It relies on our company saving the commit hash then comparing what has changed over time. That is a very arduous process. But if there are release versions or tags then it will be much easier to track things properly. Especially when it comes to validating versions/snapshots.

Also, having a branch labelled Indigo-devel but supports Indigo, Kinetic, and Bionic is really confusing. When I first looked at the repo, based on the branch names, I thought Hydro, Indigo, and Melodic were the only versions supported.

[gavanderhoorn]

This repository has never seen a 'release', so I'm not sure how we would go about tagging any.

This makes it significantly harder to ensure the differences between our snapshot and the current status of the repository. It relies on our company saving the commit hash then comparing what has changed over time

without some more explanation, your description sounds like how I could approach tracking upstream changes with something like Git:

• fork upstream
• keep fork at a specific hash (ie: this would be your snapshot)
• whenever needed/convenient: run a git diff between your fork's HEAD (or a specific hash) and upstream's HEAD

In lieu of releases, comparing hashes is exactly what I would do.

That is a very arduous process

Again: I'm not sure I understand you correctly.

Are you making file-system snapshots, instead of keeping Git commit history around?

If yes: that would indeed make things more complex, but not too much actually: hashes would essentially be equivalent to version numbers, and .zips / .tars could be named accordingly.

If you have to compare file systems/directories anyway, I'm not sure how having tags or version numbers would make this easier.

But if there are release versions or tags then it will be much easier to track things properly.

Could you clarify how having version numbers would make it more convenient?

In any case, as I wrote above: there are no releases, so no release versions, nor tags.

Also, having a branch labelled Indigo-devel but supports Indigo, Kinetic, and Bionic is really confusing. When I first looked at the repo, based on the branch names, I thought Hydro, Indigo, and Melodic were the only versions supported.

this may come down to unfamiliarity with an accepted practice in ROS development: branch only when absolutely necessary.

This is a community (ie: volunteer) maintained project.

Introducing release-specific branches just because there is a new ROS release would introduce quite a bit of maintenance overhead: either we'd have to backport things, or keep fast-forwarding / mirroring multiple branches.

[gavanderhoorn]

@jTinkerTs: friendly ping?

[jTinkerTs]

Sorry, things have been really busy for me lately.

I was inquiring about the versions because the company I work for uses a CI/CD pipeline infrastructure for thirdparty packages. We get a "snapshot" of the thirdparty repository by using the "download code" functionality of github. For example, the following URL would provide a snapshot of the repository: https://github.com/ros-industrial/kuka_experimental/archive/refs/heads/indigo-devel.tar.gz. If the indigo-devel were a released version like v1.0.0 or something, we could ensure that we always get the same version since 1.0.0 would be considered a locked and stable version of the code.

However, since indigo-devel is just a branch, that URL will always provide the latest commit. If the indigo-devel were a released version of the repository then it would be possible to use that same link to always pull the exact same snapshot of code, whether we do it in 2022 or 2030. Generally thirdparty software has release versions or tags in order to differentiate when something has been developed, tested, and ready for release to the general public. So, taking those specific releases or tags is a way to determine when code is considered stable. The company I work for has to validate the thirdparty software which we use. So a stable, tested, and released version of the software is necessary.

I am not aware of what ROS's project/packaging requirements are, so I can't speak to any of that. However, from a purely software standpoint, release versions or tags help track and maintain trackable, testable, deployable, and validate-able code. Since I am not aware of ROS's requirements, this may just be a conflict in terms of how we and they maintain source code.

Thanks for following up!

[jTinkerTs]

Here is an example of what I am talking about, using this URL, we could always get the same version of KDL's code: https://github.com/orocos/orocos_kinematics_dynamics/archive/refs/tags/v1.3.0.tar.gz. Whether we use that link in 2022 or 2030, the contents will be the exact same. The most important part of versioning is ensuring stability of code.

Plus, with versions you can easily compare what has changed. For example, this link shows what has changed with released, stable builds of KDL: orocos/orocos_kinematics_dynamics@v1.4.0...release-1.3. That functionality can't be done with commit hashes. It also helps track the bugs related to a version and when they were fixed. As well as helping determine what has changed and whether going to a newer version of the software is beneficial or not. Anyways, I don't know if it would be possible or practical for this repository.

[gavanderhoorn]

I'm well aware of how software is/should be versioned.

My main question was about how you/your company compares releases/different versions.

However, from a purely software standpoint, release versions or tags help track and maintain trackable, testable, deployable, and validate-able code.

Pedantic obviously, but tbh, I don't really see the difference between commit hashes and versions or tags. Certainly not for the purposes you describe.

The former (versions) are completely unknown to Git, the latter are just labels for humans pointing to specific commits.

All the diffing/comparing functionality works with hashes as well as it does with tags. See below.

with versions you can easily compare what has changed

only if you use a VCS, or you trust the author/maintainer of the code you're trying to diff (ie: trust (s)he has mentioned changes in the changelog or a similar document).

For example, this link shows what has changed with released, stable builds of KDL: orocos/orocos_kinematics_dynamics@v1.4.0...release-1.3. That functionality can't be done with commit hashes.

Hm?

So this doesn't work for you: orocos/orocos_kinematics_dynamics@ef9b0ee...3213bb7? Those are two random commits, but it shows the idea I believe.

If the indigo-devel were a released version of the repository then it would be possible to use that same link to always pull the exact same snapshot of code, whether we do it in 2022 or 2030

So this doesn't work for you: https://github.com/ros-industrial/kuka_experimental/archive/f8ad98609cbcad56dbb3ae26ff9d373259b52b80.tar.gz? Again a random commit, but ...

I am not aware of what ROS's project/packaging requirements are, so I can't speak to any of that.

This isn't really anything to do "with ROS".

It's just a coincidence this repository hosts ROS packages, and at the same time has never been tagged/been released.

---

When working with 3rd party repositories (by which I mean: not under my control), I typically:

• fork if I'm concerned about continuity (ie: external repositories disappearing)
• specify versions (ie: commits/tags, not branch names) in scripts/.rosinstall/.repos files if I'm concerned about reproducability (ie: avoid tracking moving upstreams)

Both of these appear to be concerns you have, with the second the one we're discussing here.

Commit hashes should work just as well as tags for this, as they're supposed to be immutable (hashes are, tags aren't -- well, new ones can be made with the same name).

[gavanderhoorn]

I'm going to close this, assuming we've dealt with the immediate issue(s).