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?
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.
When building images, always tag them with useful tags which codify version information, intended destination (
test, for instance), stability, or other information that is useful when deploying the application in different environments. Do not rely on the automatically-created
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.
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.
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?
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.
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
It’s quite simple and still in progress, but in case anyone is interested.
Thanks for spotting the builder failure, and for your great archival script! Both are very well appreciated
Fantastic. Thanks for sharing.
Ooh, nice license too. Cheers.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.