LMK what you think - discussed this with @flaunderg - currently we publish artifacts internally by explicitly triggering a build from Jenkins. the produced artifact is put in artifactory at fw-/fw-- - and that's when we set a git tag "fw--version" in the repo.
we suggest that - only when creating a new tag for "main" branch, two additional things will happen:
the version.rs file will be overwritten, with the auto-incremented version (current is 0.1, so next is 0.2 etc.)
the benchmark will be run and BENCHMARK.md and benchmark_results.png will be committed
so - when someone builds (or if we choose to publish artifacts from "main") - we'll be able to tell the binary version, and not just have to rely on commit # (which we can also add to the version info as with vw, btw).
this way there will be less potential for conflict when we merge branches where we already published artifacts to try them out - the version will always be taken from main.
if main was promoted and you pull - you'll get the updated version.
LMK what you think - discussed this with @flaunderg - currently we publish artifacts internally by explicitly triggering a build from Jenkins. the produced artifact is put in artifactory at fw-/fw-- - and that's when we set a git tag "fw--version" in the repo.
we suggest that - only when creating a new tag for "main" branch, two additional things will happen:
so - when someone builds (or if we choose to publish artifacts from "main") - we'll be able to tell the binary version, and not just have to rely on commit # (which we can also add to the version info as with vw, btw). this way there will be less potential for conflict when we merge branches where we already published artifacts to try them out - the version will always be taken from main. if main was promoted and you pull - you'll get the updated version.