Add revision to the version of Rust tools

[tailhook]

Currently version reported by edgedb --version (i.e. written in Cargo.toml) is 1.0.0-alpha.5 but it should contain revision 1.0.0-alpha.5+2020010101. This is needed to implement version check edgedb/edgedb-cli#89

[elprans]

Hm. We already do this for nightly builds: https://github.com/edgedb/metapkg/blob/b28cbb2c3f9b451ae8d93accbb5277f04c343371/metapkg/packages/rust.py#L17-L22

Am I missing something?

[tailhook]

I need it for stable builds.

[tailhook]

By the way, for nightly full version is also:

edgedb-cli_1.0.0-alpha.5+d20200928.gb421e2332_2020092800~nightly

I.e. I have suspicion is that if we rebuild nightly, it will get different revision but the same version part.

[elprans]

I need it for stable builds.

But we do proper version bumps for release builds, no?

[tailhook]

No there are two alpha.5 releases:

field	value
5
basename	"edgedb-cli"
slot	null
name	"edgedb-cli"
version	"1.0.0-alpha.5"
revision	"2020082622"
architecture	"x86_64"
installref	"/archive/linux-x86_64/edgedb-cli_1.0.0-alpha.5_2020082622"
6
basename	"edgedb-cli"
slot	null
name	"edgedb-cli"
version	"1.0.0-alpha.5"
revision	"2020082816"
architecture	"x86_64"
installref	"/archive/linux-x86_64/edgedb-cli_1.0.0-alpha.5_2020082816"

[elprans]

Hm. My understanding is that the "revision" part is for packaging/build only, and the "version" part is for the actual version of the code being built. If you've made changes to the code and want to re-release, then a version bump is mandatory. Nightlies take care of it by including the date and the git revision in the version part. Non-nightlies should have their Cargo.toml version bumped accordingly.

[elprans]

All of this would make more sense once we get rid of the alpha label, of course.

[tailhook]

Even after alpha if I'm currently on 1.0.0-20201111 and we have rebuilt CLI it should be updated to 1.0.0-20201112. Or do you say that we will never release a new binary with the same version but different revision? (I remember that we use revision for patch releases of the EdgeDB server).

[elprans]

Or do you say that we will never release a new binary with the same version but different revision?

Should we? I think that would be against the letter of SemVer, wouldn't it?

I remember that we use revision for patch releases of the EdgeDB server

That's only an artifact of being at the alpha stage. Once we switch to stable numbering, we'd be using x.y.z+1 for patch releases as expected.

[tailhook]

I remember that we use revision for patch releases of the EdgeDB server

That's only an artifact of being at the alpha stage. Once we switch to stable numbering, we'd be using x.y.z+1 for patch releases as expected.

This is weird. What stops us from making 1.0-alpha5.1 ? I think switching this later may break some server install machinery.

Also I still don't understand what to do with the "check for update" on CLI tools. Should I just ignore minor updates and hope there will be no important minor updates in the alpha/beta release cycle?

[elprans]

This is weird. What stops us from making 1.0-alpha5.1 ?

Actually, nothing, it's still valid SemVer and we should probably use this approach. My objection was specifically against using automatic packaging "revision" in semver metadata as a distinguishing factor in versions. I'm actually equally fine with 1.0-alpha.5.1 and 1.0-alpha.5.20201112

[tailhook]

Honestly, I don't think we should make revision in binary path either. In deb/rpm packages revision is needed to distinguish upstream vs package version. Since our package == upstream we don't need anything useful there.

Anyway, what has to be done? Should we start using 1.0-alpha5.1 tags and never re-release with the same tag? Will it work if we tag this way? (by the way +xxx is the build version by semver spec, so it's fine if we add it too).

[elprans]

Should we start using 1.0-alpha5.1 tags

I think so.

Will it work if we tag this way?

I think we should bump the version in Cargo.toml and use that precisely for releases (basically, the opposite of what we do for nightlies). So, if you made a release and realized that there's a bug, edit Cargo.toml and re-run the release workflow. This approach would require a small change to metapkg. I can do it if there's agreement that this is what we want to do.

[tailhook]

Generally it's what I do for my other open-source stuff: make a commit with changed Cargo.toml/Cargo.lock and tag this commit. So sounds good to me.

[elprans]

Done.