automatic calendar-versioning based releases

[neelgala]

This PR upgrades the github actions script to create a new release each time the master is updated. The release name is based on calendar-versioning : YYYY-MM-DD.MINOR. Eg. 2022-02-28.1.

I have always found the lack of linear versioning on spike a major pain-point to figure out where my local build is with respect to the master. Hence this PR.

A probable next step is to include the recent-tag into the cli parser (via the build process) which can be queried later via a --version cli arg

I managed to fix the configure scripts to capture the recent most tag and use it as a VERSION string in the help command.

[neelgala]

let me know if I should delete the VERSION file in the root directory since with this PR it becomes obsolete.

[scottj97]

The VERSION file is still here, now unused, with a no-longer-accurate version string. [Edit: sorry, I see you asked about this; certainly it should not stay in its current form.]

Typically we manually update the ChangeLog when there's a release. Where/when does that happen in the release process now?

I maintain my own fork of Spike and I haven't had the problem that this is attempting to solve. Git already has good tools for seeing where my branch is, relative to the upstream. I'm skeptical of this PR for all these reasons.

[scottj97]

Who is StephaneBour?

[neelgala]

The github action file is provided by that user : https://github.com/StephaneBour/actions-calver

[neelgala]

The VERSION file is still here, now unused, with a no-longer-accurate version string. [Edit: sorry, I see you asked about this; certainly it should not stay in its current form.]

Typically we manually update the ChangeLog when there's a release. Where/when does that happen in the release process now?

I maintain my own fork of Spike and I haven't had the problem that this is attempting to solve. Git already has good tools for seeing where my branch is, relative to the upstream. I'm skeptical of this PR for all these reasons.

I will make the suggested changes and update in a few minutes.

I am mostly interested in versioning the master-branch because that is what most folks use and it typically includes quick patches that are required for immediate consumption. - rather than a old tagged release. For example the docker-image used by the riscv-arch-test group needs to use the latest version of spike. By having a calver system on the master one can visually figure out how old the docker image version of spike is - instead of using git tools and commit# to figure that out.

Similarly, spike is also treated as a pseudo-golden mode by the riscof compliance framework. And therefore we would like to capture spike's version used by the vendor in the compliance report. This PR will help achieve that.

Also Changelogs are not updated on every commit to master, so what is the protocol of making a Changelog entry ?

Your convention of Changelog based manual releases can continue as is since it follows semantic versioning. The repo will basically have 2 sets of releases : calver based which is bleeding edge and semantic based which indicates stable ratified releases.

[neelgala]

@scottj97 @aswaterman any thoughts ?

[allenjbaum]

From the point of view of arch-tests: we need to be able to track precisely which version of all tools are used so if a vendor reports a problem, we can confirm using exactly the same version that they used the problem (or tell them they are using an outdated version). The test reports will list the version number, and when tests for a ratified spec are merged, we need to identify which version of tools were ued to generate the test reports.

[scottj97]

I guess I'm okay with having two parallel release tracks, but it seems there should be a bigger distinction between the rolling calver releases and the "official" semver releases. Would someone seeking the newest "release" even realize there's such a choice?

Also there's an incremental compilation issue here. Previously when the VERSION file changed, the Makefile would detect that spike.cc needs recompilation. That won't happen anymore, resulting in the Spike binary reporting an out-of-date version number.

To fix that, you could change spike.cc back to using an include file to get the version, and a new Makefile rule to create the version file, that only touches the file if its contents have changed. Something like the $(if ...) that this guy uses, though you don't need md5sum.

[aswaterman]

Two release tracks seems a bit confusing. I'd rather stick with manual releases, but increase the frequency of them.

As a compromise, we can include git commit information in the Spike version string, like the Linux kernel does... something like "Spike RISC-V ISA Simulator 1.0.1-dev-b1fcb02-dirty (2022-03-15)". (The hash[-dirty] comes fromgit describe --always --dirty and the commit date is git show --format=%cs).

This would seem to address the originally stated problem of figuring out local position wrt. master branch.