Last month I tried dusting off some earlier experiments with Force, and it turned out that the local Dockerfile from ~1 year ago no longer builds. Investigating the issue revealed that the same issue seems present in this repository.
I'm not asking for being able to build a bit-exact image several years down the line, but it would be nice if it was possible to build something resembling the image that was built at release time at a later time.
The main issues for the non-reproducible builds seem to be the lack of version numbering of the base image, and the lack of version numbers/git tags for the force-udf repository.
If you're going to put version numbers on the base image and force-udf, here's a summary of what I recently learned when fighting Python on version numbers:
My suggestion for the base image: 1.<ASCII-sortable version number>.<GDAL-version>, which for the current image would be something similar to 1.202512031644.3.11.3. It's not beautiful, but has some nice properties which are practical for scripts.
The number scheme ensures that the most recent base image release from you gets the highest version number, so it's possible to revert to an older GDAL version in a later release if that turns out to be necessary. The ASCII-sortable number ensures 1 is sorted before 10 which avoids having to do special-casing in various utility scripts.
For the ASCII-sortable version number, I would suggest using a date-based number. They are easy to generate automatically, and people are unlikely to interpret a timestamp as something carrying semantic information, the only gotcha I see is to have sufficient precision to make multiple releases in the same day, so include minutes (or seconds) in the timestamp just to be sure: YYYYMMDDHHmm. It's tempting to put some kind of visual separator between the parts for readability, but Python does not appreciate "01" as a component in a version number.
Zero-padding the major version has the same problem as a zero-padded component in Python, so that's why I'm suggesting to start on 1. This gives 8 more major versions before ASCII sorting becomes an issue, and I would recommend to just keep the major at 1 forever unless there's some future technical reason to bump it.
It's possible R has other idiosyncrasies that should also be considered when selecting a version number scheme, but I have no experience with R.
Last month I tried dusting off some earlier experiments with Force, and it turned out that the local Dockerfile from ~1 year ago no longer builds. Investigating the issue revealed that the same issue seems present in this repository.
I'm not asking for being able to build a bit-exact image several years down the line, but it would be nice if it was possible to build something resembling the image that was built at release time at a later time.
The main issues for the non-reproducible builds seem to be the lack of version numbering of the base image, and the lack of version numbers/git tags for the force-udf repository.
If you're going to put version numbers on the base image and force-udf, here's a summary of what I recently learned when fighting Python on version numbers:
My suggestion for the base image:
1.<ASCII-sortable version number>.<GDAL-version>, which for the current image would be something similar to1.202512031644.3.11.3. It's not beautiful, but has some nice properties which are practical for scripts.The number scheme ensures that the most recent base image release from you gets the highest version number, so it's possible to revert to an older GDAL version in a later release if that turns out to be necessary. The ASCII-sortable number ensures 1 is sorted before 10 which avoids having to do special-casing in various utility scripts.
For the ASCII-sortable version number, I would suggest using a date-based number. They are easy to generate automatically, and people are unlikely to interpret a timestamp as something carrying semantic information, the only gotcha I see is to have sufficient precision to make multiple releases in the same day, so include minutes (or seconds) in the timestamp just to be sure:
YYYYMMDDHHmm. It's tempting to put some kind of visual separator between the parts for readability, but Python does not appreciate "01" as a component in a version number.Zero-padding the major version has the same problem as a zero-padded component in Python, so that's why I'm suggesting to start on 1. This gives 8 more major versions before ASCII sorting becomes an issue, and I would recommend to just keep the major at 1 forever unless there's some future technical reason to bump it.
It's possible R has other idiosyncrasies that should also be considered when selecting a version number scheme, but I have no experience with R.