BinderHub effectively works as a continuously deployable repository, where every merge is deployable. However we still have some tags, and there is an open issue about a 1.0.0 release.
What do you think about formalising this "always deployable" state of BinderHub and treating every merge as a mini release? The artefacts from this repository are the container images and the Helm chart.
This either means forgetting about tags completely, the Helm Chart versions are the definitive record of versions, or automatically creating tags corresponding to the Helm Chart version after every merge and disable any workflows triggered by tags.
This requires adding an option to chartpress to get YYYY.MM.DD-HHMMSS from the last commit (which should be a merge commit created by GitHub, so should always have a reliable timestamp).
The reason for keeping the git commit in YYYY.MM.DD-HHMMSS-gGITCOMMIT is to easily tie it back to the source commit.
Alternatively we could change the first part to YYYY.MM.DDHHMMSS which means we can also use that for the PyPI package version if we wanted to push it.
Proposed change
BinderHub effectively works as a continuously deployable repository, where every merge is deployable. However we still have some tags, and there is an open issue about a 1.0.0 release.
What do you think about formalising this "always deployable" state of BinderHub and treating every merge as a mini release? The artefacts from this repository are the container images and the Helm chart.
This either means forgetting about tags completely, the Helm Chart versions are the definitive record of versions, or automatically creating tags corresponding to the Helm Chart version after every merge and disable any workflows triggered by tags.
This requires adding an option to chartpress to get
YYYY.MM.DD-HHMMSSfrom the last commit (which should be a merge commit created by GitHub, so should always have a reliable timestamp).The reason for keeping the git commit in
YYYY.MM.DD-HHMMSS-gGITCOMMITis to easily tie it back to the source commit.Alternatively we could change the first part to
YYYY.MM.DDHHMMSSwhich means we can also use that for the PyPI package version if we wanted to push it.Related issues: