Support issue tracking through versioning

[slack-coder]

Help end users communicate the rad version they run by communicating whether they are running release builds. Many end users are using the client built directly from the project's master branch.

Including the target architecture can help too.

Suggestions given:

• 0.6.1-ab736f (commit hash appended for dev releases)
• 0.6.1-(current/post/dev)-ab736f (post or dev describe it is after 0.6.1)
• 0.6.1-ab736f+armv7 (armv7 is the target of the build, the '+' is a semantic versioning compatible way to include build metadata)

Alternative:

• use development branches, and use master only for releases

Related links

• https://www.keiruaprod.fr/blog/2020/05/12/include-version-in-rust-binary.html
• https://semver.org

[gsaslis]

Thanks for thinking about this @slack-coder ! I've also been hit by running a different version than the one I was following instructions for at some point, so this would really help ease that pain in the future.

Just one clarification, considering 0.6.1 is the latest released version right now, shouldn't the examples in the description have the 0.6.2- prefix, considering that these are pre-release versions we'd be talking about (as per semver #9 convention - https://semver.org/#spec-item-9 ) ?

[slack-coder]

Just one clarification, considering 0.6.1 is the latest released version right now, shouldn't the examples in the description have the 0.6.2- prefix, considering that these are pre-release versions we'd be talking about (as per semver #9 convention - https://semver.org/#spec-item-9 ) ?

Maybe we should do this? The problem is we, and most others, don't track what the next release will be early on, whether 0.6.2 or 0.7.0. The pre-releases tend to be phased in later, but just before the next release.

[erak]

Including the commit hash sounds good, but from my understanding this should be added after the +. I'd slightly change the proposal by @slack-coder and throw in the following, considering

1. release builds: 0.6.1-release+commit.<sha>
2. development builds: 0.6.2-dev+commit.<sha>, whereas the above was the previous release. In case we want to have nightly builds a some point, dev could be easily replaced by nightly and that would perfectly fit the naming scheme.

I'm not sure if we need to include the target for now, since that information could be easily retrieved from the user.

[erak]

I'll take a quick look at the implementation, such that we hopefully only need decide on and apply the final scheme.

[erak]

I created a PR that adds build information retrieved from git to the version output of the rad binary. For now it will create a uniform version string that follows this pattern:
rad <version>-<branch>+sha.<commit>, so e.g. rad 0.6.2-master+sha.5d39dd0.

In order to differentiate release builds, we'd need to adjust the release flow and use a release branch.

With this in place, we could read the branch name in build.rs and create more sophisticated version strings like rad 0.6.2-master+sha.5d39dd0 for development builds and just rad 0.6.2 for release builds.

[cloudhead]

I think release builds should just look like 0.6.1, since that points to a tag, any other information is redundant. Then development builds can contain a short hash, and the problem is solved, so 0.6.1+abcdef1 or 0.6.1-abcdef1

[erak]

Ok, cool! Adjusted #242 such that it only appends the commit hash if not on branch release. We need to make sure to use that branch for the releases then. CCing @adaszko here as well.

[slack-coder]

To be clear, the suggestion was to include the commit information when reporting the version using the 'version' subcommand and help, not in naming release packages.

Are we moving to a breaking release, hence 0.7.0 instead of 0.6.2?

What about appending a '-dev' to the cargo package versions until a release build? It will be clear when users build these packages from a work-in-progress version, and '-dev' can flag whether the commit hash is be included in reporting the version.

[erak]

@slack-coder That's exactly what #242 does: it reports a version string with rad --version that contains a commit hash when built from all branches that are not named "release".

The crate version needed to be changed in order to be ahead of the latest release, such that rad 0.6.2+<sha> points to a pre-release build of 0.6.2. (Before the PR the crate version was 0.6.0, which was probably missed during the last release).

I think we do not need to change the crate version such that it contains -dev (which AFAIK also not follows the Rust semver conventions for crates). If the information is only needed in the version string, it can be easily added via build.rs.

[slack-coder]

The crate version needed to be changed in order to be ahead of the latest release, such that rad 0.6.2+<sha> points to a pre-release build of 0.6.2. (Before the PR the crate version was 0.6.0, which was probably missed during the last release).

The change is good, the question is whether we're at patch level changes now since the 0.6.1 release. @cloudhead ?

@slack-coder That's exactly what #242 does: it reports a version string with rad --version that contains a commit hash when built from all branches that are not named "release".

Thats good, it would require tying the code to a branching model which is why using the cargo version string might be better to source whether the commit hash be used or not.

I think we do not need to change the crate version such that it contains -dev (which AFAIK also not follows the Rust semver conventions for crates). If the information is only needed in the version string, it can be easily added via build.rs.

Its compatible as per the cargo documentation https://doc.rust-lang.org/cargo/reference/resolver.html#pre-releases.

[erak]

The crate version needed to be changed in order to be ahead of the latest release, such that rad 0.6.2+<sha> points to a pre-release build of 0.6.2. (Before the PR the crate version was 0.6.0, which was probably missed during the last release).

The change is good, the question is whether we're at patch level changes now since the 0.6.1 release. @cloudhead ?

Ah, I understand. Maybe the next release should already be 0.7.0, since we're also rolling out breaking changes with the seed incompatibilities?

@slack-coder That's exactly what #242 does: it reports a version string with rad --version that contains a commit hash when built from all branches that are not named "release".

Thats good, it would require a tying the code to a branching model which is why using the cargo version string might be better to source whether the commit hash be used or not.

Agreed. Tying it to the branching model is not ideal, but was the simplest solution for now and also meant to be discussed.

I think we do not need to change the crate version such that it contains -dev (which AFAIK also not follows the Rust semver conventions for crates). If the information is only needed in the version string, it can be easily added via build.rs.

Its compatible as per the cargo documentation https://doc.rust-lang.org/cargo/reference/resolver.html#pre-releases.

Ah, cool!