Open douardda opened 3 years ago
On the experimental branch my usual workflow is: (1) make code changes, build & test, (2) make commit, (3) upload binaries, so the binaries actually include the new changes but appear to be built from the previous commit. Actual production release builds are not done by me, so would be based on a clean git checkout.
shouldn't be helpful/preferable to automate this workflow (using travis)? You make your code improvements, tests, builds and commits (in no particular order :-) ), and when it's ok, tag the commit which automatically compile the binaries and make the resulting firmwares available for download. Generated assets should not be the result of a hand-managed process.
Having "tracability" is a (very) good thing (which the version visible in the "version" menu is actually), but if it "lies" about what git revision it has been used to be compiled, it defeat the purpose of embedding the git revision in the version string in the firmware (ideally revisions and binary files should be gpg-signed, but hey, maybe not required for now...)
David
Just uploaded firmware 2_2-st7793.bin listed in 20200916 pre-release, however the "version" menu says the version is git-20200916-dc67cf5 which is the revision just before the one tagged 20200916 (so it lacks rev 05aa3ce10a5eafee0c11525bb8e9374bdf84f6c3 which seems to fix something, not sure what since the commit message is not in english).
Maybe it's time for a nice travis config to handle this release process automatically ;-)
Thanks, David