Improve versioning of status-go

[adambabik]

Problem

The current versioning of status-go is inconsistent, not automated and does not follow semver rules.

Implementation

The most important goals are to make it consistent and automate the process, if not fully, at least to some degree.

A proposed flow:

1. Let's assume the current version in develop is 0.10.0,
2. A new release branch is created and called release/0.10. Its version should be 0.10.0. At the same time, the version in develop should be bumped to 0.11.0,
3. The first binary built in release/0.10 should report a version 0.10.0-beta.1, the next one 0.10.0-beta.2 and so on,
4. When it's decided that the release branch is good, a tag called 0.10.0 should be created which should trigger a build with version 0.10.0 (note a missing -beta label),
5. The version in release/0.10 should be bumped to 0.10.1,
6. Builds in develop will have versions 0.11.0-alpha.1, 0.11.0-alpha.2 and so on.

Additionally, there should be more information about the build like commit SHA, datetime, geth version etc.

When we have a few tags, we can automate it further as a proper version can be figured out based on a branch name and history of tags.

Creating a release branch with bumping commits should be created as a bash script and encapsulated in Makefile. It should not be a manual process as it's troublesome.

Problems that this flow solves:

1. Clear distinction between develop and release branches,
2. Even if a release is being tested, it's possible to merge pull requests into develop or even work on two releases at the same time,
3. History of changes and easy to follow progress of development of statusd,
4. It will allow taking advantage of Releases section in Github,
5. Consistent versioning will simplify reporting and fixing bugs.

Acceptance Criteria

1. There is a command to create a new release branch: make release-branch. It should create a branch and proper commits bumping versions. It should be run only from develop,
2. There is a command to create a release tag make release-tag which can be run only from a release branch. It should create a proper tag and commits bumping versions,
3. None of these commands should push anything automatically. It should be done manually after verifying everything is correct,
4. There should be additional build information like commit SHA, datetime and geth version,
5. statusd version should print version and build information,
6. Starting statusd should print an INFO log with version and build information.

Notes

The version is currently hardcoded in https://github.com/status-im/status-go/blob/develop/geth/params/version.go. It consists of four components: major, minor, patch and meta. Note: meta is pretty arbitrary but has a defined format: http://semver.org/#spec-item-10

There are also additional build flags that should be reviewed https://github.com/status-im/status-go/blob/develop/Makefile#L36.

[tiabc]

Decreasing priority as this issue doesn't block anything.

[athos-ribeiro]

Hello,
I would like to work on this. I just opened #501 to make sure I understand the issue correctly. While working on that PR I had a few questions:

• You propose that a build should be triggered whenever a tag is created. Should this be done on the developer machine, or should it be implemented on a CI or build server side?
• You propose that alpha and beta values should be bumped on each build. Should this be done on the developer machine, or should it be implemented on a CI or build server side?

Note that There is one detail missing on the PR: the params.Version should be set to Major.Minor.Patch (no Meta) in case Meta is blank. Would that be an acceptable approach? (note that that is the behavior that the Makefile targets are expecting).

If these changes are OK, I will proceed to work on the other points in the acceptance criteria.

[athos-ribeiro]

#504 fails to pass on CI tests on gometalinter unparams because we are passing constant values to the function that builds the version string.

geth/params/version.go:25:25:warning: parameter major always receives 0 (unparam)
geth/params/version.go:25:32:warning: parameter minor always receives 9 (unparam)
geth/params/version.go:25:39:warning: parameter patch always receives 9 (unparam)
geth/params/version.go:25:50:warning: parameter meta always receives "unstable" (unparam)

We could just use the constants in the function without passing them as params, but I did it this way to make it easier to test the function. Any thoughts here?

[adambabik]

@athos-ribeiro, thank you for your contribution! Let's work closely on this one as it's pretty complex and requires some testing by org members.

I will review your PRs shortly.

You propose that a build should be triggered whenever a tag is created. Should this be done on the developer machine, or should it be implemented on a CI or build server side?

It will be done on a CI server but it doesn't matter. There should be a shell script that anyone can execute that it should create proper branches and tags.

You propose that alpha and beta values should be bumped on each build. Should this be done on the developer machine, or should it be implemented on a CI or build server side?

The same answer.

Regarding versioning. Currently, we keep some values in version.go but it's not necessary. We can dynamically provide it using -ldflags and calculate it from a git tag. git describe can be useful to do that. So, I think that if the latest tag in develop branch is 0.10.0, a new build in this branch should report 0.11.0-alpha.0. If the latest tag is 0.11.0-alpha.0 then it should report 0.11.0-alpha.1 and so on.

[athos-ribeiro]

I will work on #501 ideas proposed on your comments and then drop #504 in favor of obtaining versions from the latest git tag. I do have one question though: should we still update versions on version.go after the bumps?

[athos-ribeiro]

For the proposed flow, what would define the current version in develop? If it is a tag, then I probably did not understand the proposed flow:

Bullet 1 infers version 0.10.0 in develop, while the 0.10.0 tag is only created in bullet 4.

Should I understand that the current version in develop is actually whatever we have in the latest tag with the MINOR version bumped (MINOR + 1) since we are not relying on version.go?

In this case, I still have a few questions for the proposal, which came up while refactoring #501, as requested :

1. Let's assume the current version in develop is 0.10.0, i.e.: there is a branch named release/0.9 or a tag 0.9.?. Is this assumption right? Otherwise, where should this version be fetched from?
2. A new release branch is created and called release/0.10. Its version should be 0.10.0 (whenever we create a first tag). At the same time, the version in develop should be bumped to 0.11.0 (Where? Should we just assume that, as pointed in 1 since we now have a 0.10.0 branch?).
3. The first binary built in release/0.10 should report a version 0.10.0-beta.1, the next one 0.10.0-beta.2 and so on (where should we keep the meta version information, if we are not creating tags for each build?).
4. When it's decided that the release branch is good, a tag called 0.10.0 should be created which should trigger a build with version 0.10.0 (note a missing -beta label). This is the point where I got a bt confused, since we are not relying on version.go
5. The version in release/0.10 should be bumped to 0.10.1. Should we also assume this based on the latest tag?
6. Builds in develop will have versions 0.11.0-alpha.1, 0.11.0-alpha.2 and so on. Where should we store the meta versions?

[adambabik]

@athos-ribeiro

should we still update versions on version.go after the bumps?

Eventually, we won't have version.go anymore. A version should be derived from a tag because that's the only reliable way to pin a particular commit to a version.

Bullet 1 infers version 0.10.0 in develop, while the 0.10.0 tag is only created in bullet 4.
Should I understand that the current version in develop is actually whatever we have in the latest tag with the MINOR version bumped (MINOR + 1) since we are not relying on version.go?

So, currently, in version.go we have 0.9.9. We can create a new tag right now with version 0.9.10 and treat it as the latest one.

Let's assume the current version in develop is 0.10.0, i.e.: there is a branch named release/0.9 or a tag 0.9.?. Is this assumption right? Otherwise, where should this version be fetched from?

We don't need a release branch. We can work with the fact that there are no release branches yet.

I will answer all your questions below. Let's only assume that we don't care about building binaries for now but a new release is a new git tag. Sorry for the confusion, I shouldn't mix making releases and binaries in the same paragraph.

Let's assume that we have only one tag 0.9.10. When we run make release-branch in develop, a new branch release/0.10 is created. Next, we can create two releases, one from develop and one from release/0.10. When we create a release from develop, our script will detect that we are on develop and see only 0.9.10 tag, so it should create a git tag named 0.10.0-alpha.0. When we create a release from release/0.10 branch, our script should figure out it's a release branch, check existing tags 0.10.* and create a new release (= a new tag) named 0.10.0.

It can get tricky now. Let's assume that we did a few releases in release/0.10 branch and the latest tag is 0.10.3. We can assume that all commits in release/0.10 are included also in develop. Now, when we make a new release from develop, our script will return the latest tag which is 0.10.3, so the release version should be 0.11.0-alpha.0. The next one from develop will be 0.11.0-alpha.1 because the highest is 0.11.0-alpha.0.

---

When writing that explanation, I realized that the logic the script needs to embrace is pretty complicated. We can make it much easier for now and instead of relying on script's logic, we can create a simpler script to just make specific releases. For instance ./release.sh minor will look for the highest tag and create a new one with a minor bump (e.g. the highest was 0.10.3 so the new one will be 0.11.0). More generic, this script should take a param ./release.sh $VERSION $PRE-RELEASE where $VERSION = major | minor | patch and $PRE-RELEASE = alpha | beta.

I believe there is already a semver implementation in bash, so what would be needed here is some logic to detect the highest git tag in a branch, which also should be easy.

When we confirm that this manual script is good, we will be able to move it further and automate it.

I am happy to chat more interactively on Riot if you would like to. My nick is @adamb:status.im.

[mandrigin]

Closing it, the progress will be tracked in status-im/swarms#52