Open ailrst opened 2 months ago
This breaks the sbt build, so if the idea is to deprecate the sbt build then that should be done fully.
This doesn't seem to generate the version Scala file automatically upon building with mill, only if the updateVersion
mill command is run. Is that the intended behaviour? It wasn't clear from what you've written here that I had to do that.
Its supposed to generate the version Scala file automatically when building, and it seems to have compiled successfully using mill in CI with mill build
.
I wasn't intending to break sbt build, but was deliberately not implementing the whole version updating logic in sbt. Just the Version.scala generation could be implemented in sbt based on the VERSION file, I think that would be enough. Alternatively we could just check in Version.scala, but would probably want to leave it in the gitignore.
Neither ./mill.bat compile
or ./mill.bat run
will create Version.scala for me, only ./mill.bat updateVersion
works.
This adds a version number to BASIL's help text based on
git describe --tags
. It shouldn't cause issues when git isn't available, falling back to whatever is in the VERSION file. The VERSION file stores the version number of the last tagged release.git describe --tags
if git is available at build-time, or the contents of the VERSION file if not.The Scala version file is generated each build is not checked in.
This means the process for making a release is
git tag -a "$(cat VERSION)"
Alternatively, just adding a git tag will bump the version file on the next build, which will mean the the tagged commit has the old version file, but builds with the correct version when git is present.