Will the new releases be tagged by version anymore in docker hub?

I noticed recent releases 2.8.0 and 2.8.2 are not tagged by version in docker hub, is this expected behavior? Will the future releases not be tagged by version?

1 Like

Hmm… Great question!

What is your usecase for using a specific tagged release vs a more rolling-release model where you always just use what is current?

Each new release comes, I need to make sure it’s stable before deploying it to my automated pipeline. If some backward compatibility breaks (arguments, outputs, etc.), I also need to update my automated pipeline accordingly. And if something is wrong due to the latest update, I can simply revert to old versions.
I can create my own registry to archive old versions, but it will make my life easier if opendronemap can manage this.

1 Like

When building images, always tag them with useful tags which codify version information, intended destination (prod or test, for instance), stability, or other information that is useful when deploying the application in different environments. Do not rely on the automatically-created latest tag.

This has affected us at work – we now use multiple tags: one with a date stamp (think foo:20220407.105745) and one with a branch (think foo:prod). The branch tag gets reused, the date stamp doesn’t. This allows for improvements in reusability as well as very quick bisection for identifying regressions.

1 Like

We currently don’t (consistently) tag versions in docker hub. If one needs to pin a specific version, we encourage to just tag an image and push it to a separate repository.

ODM uses a rolling release model Rolling release - Wikipedia.

Yes it’s a bit more work for people that need certain stability/update guarantees.

But it’s also a lot less work for us to officially support multiple versions. So it’s a trade-off.

2 Likes

I checked the build actions in the recent 2 releases, seems you do tag the image by release version. (CPU only, but this is enough for me).
Both of them failed due to out of disk space, is it something can be fixed?

1 Like

I think this is generally yours to manage. If you need stability bolted onto a free and open source, rolling-release ecosystem, you need to build that process.

Alternatively, not speaking for Piero but for my own perception here: if you have the bandwidth to maintain this for the larger community, that could be beneficial to a wider group, and appreciated.

1 Like

I’m working on an ODM archiving project recently.
I don’t want to build docker images by my own, lacking of resources to do it, so my choice is archiving the latest build with the release tag.
I’m not sure if this way matches with the actual release version, I need to understand how the build and push pipeline is setup in ODM repository, that’s why I started to check github actions and noticed these building failure in version releases.
I’m not requesting something, as Piero already confirmed the current release model. But the building failure doesn’t seem to be a part of rolling release model, so I pointed this out

2 Likes

It’s quite simple and still in progress, but in case anyone is interested.

2 Likes

Thanks for spotting the builder failure, and for your great archival script! Both are very well appreciated :slight_smile:

2 Likes

Fantastic. Thanks for sharing.

2 Likes

Ooh, nice license too. Cheers.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.