Yeah we stopped incrementing the VERSION number in master; instead the git hash should be shown... I wonder what's different here.

I think @caybro fixed this one lately?

I think @caybro fixed this one lately?

Yeah, fixed with this PR: #16085

Ehm, that was the status-go version; ours is (will be) still wrong probably... :/

Either we update the VERSION file manually with each release, to be something "higher", or we need to figure out some generic "git-like version"

I'll try to think about something

❯ git describe --tags --dirty="-dirty"
0.6.0-6149-gace5d0f9fb-dirty

Oh, I guess that's because we have release tags in release branches. So on master branch we don't have any latest tags 🤔
Not sure what's the right way to do it then.

❯ git describe --tags --dirty="-dirty"
0.6.0-6149-gace5d0f9fb-dirty

Oh, I guess that's because we have release tags in release branches. So on master branch we don't have any latest tags 🤔 Not sure what's the right way to do it then.

Yeah, manually tagging master after each release, or manually increasing the VERSION number; I don't see much difference tbh 😄

Yeah, manually tagging master after each release

Something like this, yes. When starting a release/2.N.x branch, we could create a v2.(N+1).0-dev.0 tag on the next commit in the develop branch. Because from that point we're working on 2.(N+1) version.

Something like this, but needs to be tested. And also this sounds a bit overcomplicated :D

It will be a manual process, but I don't think that's a problem.

I find it weird to see 2.30.90 as dev version, as it's just not true 😄
And while it's not super realistic, it is still theoretically possible to have 90 patches on release branch and eventually have a real 2.30.90 version, which would conflict.

How status-go does it

I like the simplicity of status-go about versioning. We use git describe --tags --dirty="-dirty" to automatically calculate the version from tags. This is a standard functionality of git.

EXAMPLE:

I now have v3.5.0-4-g6ee62061b, which means:

• it's v3.5.0
• with 4 commits on top
• current commit it is 6ee62061b

How to apply it in desktop

We could do something similar, but there's one problem: we have vX.Y.Z tags on releases branch, not on master branch.
To fix this, as soon as the release branch is cut, we should create a tag with the next anticipated version.

And use the idea of @iurimatias of the -dev suffix.

EXAMPLE:

• We cut release/v2.30.x
• On the same commit, we create v2.31.0-dev (or `v2.31.0-alpha) tag

So until you cut a branch, you'll get versions like this: v2.31.0-dev-2-g6ee62061b.

What do you think?
cc @caybro @iurimatias @jrainville @osmaczko

lol, turned out that I already proposed this in the comment above: #12349 (comment) 😄

Yeah I like the idea too, and I said it even before 😆. This will just require some manual intervention no matter what; in the end it doesn't matter much if it's editing VERSION file manually, or creating the tag

In current master:

❯ git describe --tags --dirty="-dirty"
0.6.0-6438-g016380a2bd-dirty

Oh and turns out if I do this:

❯ git describe --tags --dirty="-dev"
0.6.0-6438-g016380a2bd-dev

it will append the -dev there automatically :)

Last remark, the only thing I'm unsure (and quite frankly the only downside) is that only @iurimatias and maybe @jrainville are able to push git tags?

it will append the -dev there automatically :)

This just shows that you have some local uncommitted changes. -dirty makes more in this case than -dev I think.

Last remark, the only thing I'm unsure (and quite frankly the only downside) is that only @iurimatias and maybe @jrainville are able to push git tags?

In status-go anyone can push tags. So I think it's the same in desktop.