dwijnand/sbt-extras

Tagging a release

dbast opened this issue · 4 comments

dbast commented

Dear sbt-extra team,

would it be possible to add a git version tag (= tagging a release) on master from time to time, e.g. when new major improvements were merged?

That would give it a reproducible version and make it possible to package the runner as package for e.g. conda-forge.

Thanks!

dwijnand commented

We discussed this in #137 and decided not to. Could you use the HEAD commit timestamp or HEAD sha instead in conda-forge?

dbast commented

Ok, if I read the mentioned issue correctly then this was about adding a version/timestamp directly inside the bash script, which was decided not to do.

The idea here is now to add the version as tag on git level with the advantages:

  • no changes on code level
  • packaging can then use the version
  • the package manager can then tell what version is installed
  • new tags in upstream repos automatically trigger a conda-forge bot (sounds maybe unbelievable, but is some very nice automation) that proposes an update to the conda-forge package, that can then be reviewed and updated.

To answer your question: Yes packaging HEAD is technically possible, but normally not accepted due to reproducibility, to avoid giving a then artificial conda-forge package version and due to the then not working mentioned bot update mechanisms.

  • 👍1
zabbal commented

I'd second that - having version/release tags in git won't require any changes to the script itself but would greatly help with packaging and reproducibility.

dwijnand commented

Yes packaging HEAD is technically possible, but normally not accepted due to reproducibility, to avoid giving a then artificial conda-forge package version and due to the then not working mentioned bot update mechanisms.

I didn't say packaging HEAD, I said packaging the HEAD sha. And instead of using an artificial package version you could either use the sha or, if you prefer something sequential, you could use the sha's timestamp.

For clarity: I'm not entirely against the idea of introducing traditional version tags in this project, but in some ways it's been nice not to have to think about them and it seems to have worked ok so far.