Version Number

[iajrz]

Versions should be semver 2 compatible, which is aligned with golang's module versioning guidelines.

I think we should start work with version "0.99.0" to begin with, which is a number that points towards v1, is below 1.x (denoting "in development"), and is far enough from v0's version number to differentiate it.

[luyzdeleon]

I would like to propose the use of build metadata outlined in Semver 2, so that we can have continous merging into the code while on the "same version".

[iajrz]

Ah, I noticed a misread in the specification which caused a flawed implementation, so this shouldn't be closed after all.

Format will be edited to conform to the format -- applied to our case, version number will look something like this:
Major.Minor.Patch-branch.commit.dirty+race

[iajrz]

In fact, the branch and commit don't quite fit into this scheme; the proper format should be Major.Minor.Patch[-dirty]+branch.commit.race, otherwise the branch name and commit hash would be used to determine precedence, and they shouldn't.

[luyzdeleon]

What would be the actionable here @iajrz ? Creating a PR ammending the docs?

[iajrz]

Action items:

• addition to mage.go to make it use tag information when available.
• Amending docs to explain what we actually do with versioning with the magefile.

[Olshansk]

@iajrz I want to create a tag & release for main https://github.com/pokt-network/pocket as a milestone finish line.

Following the instructions in https://github.com/pokt-network/pocket/tree/main/docs/build, what should it be?

[iajrz]

Tag v0.0.1-alpha.01 is a good starting point; I think the build doc needs updating.

[Olshansk]

Per https://en.wikipedia.org/wiki/Software_release_life_cycle, I'll go with pre-alpha for now, but otherwise sounds good.