Motivation

1. We want to stop operating the version manually
2. We want the versioning to be meaningful
3. We want to bind desktop/mobile to status-go by version
4. We want each develop merge PR to be addressable by version
5. We want the version to be “obviously increasing” Therefore we don’t want to use commit SHA in versioning.
6. ❓ We want to use RC versions
7. ❓ We want to identify the changes type (breaking/feature/fix) in each develop PR

What’s wrong with current proposal?

The current proposal is to auto-increment PATCH on each develop PR.

• ✅ Automatic versioning

• ✅ All develop PRs are addressable by version

• ❌ Wrong usage of PATCH

  • It’s proposed to use +hotfix.1 instead of PATCH, but this is a pain and still a wrong thing to do.

• ❌ There’s a problem with precedence of versions. According to Semantic Versioning:

  9. … Pre-release versions have a lower precedence than the associated normal version.

  10. … Build metadata MUST be ignored when determining version precedence

  This means that:

  • v1.2.3-hotfix.1 < v1.2.3
  • v1.2.3+hotfix.1 == v1.2.3

  Which is not what’s intended by us.

“Snapshot” proposal

%%{init: { 
    'logLevel': 'debug', 
    'theme': 'dark', 
    'gitGraph': {
        'showBranches': true,
        'mainBranchName': 'develop',
        'showCommitLabel': false,
				'rotateCommitLabel': true,
				'mainBranchOrder': 0
    },
		'themeVariables': {
        'git0': '#FFC400',
        'git1': '#546E7A',
        'git2': '#455A64',
        'git3': '#00E676',

        'git4': '#FF1744',
        'git5': '#546E7A',
        'git6': '#455A64',
        'git7': '#651FFF'
     }
}}%%
    gitGraph LR:

    commit tag:"v1.0.0"
    branch feat-1 order:1
    checkout feat-1
    commit
    commit
    checkout develop
    merge feat-1 tag:"v1.1.0-dev.1"
		checkout feat-1
    commit
    checkout develop
    merge feat-1 tag:"v1.1.0-dev.2"
		branch feat-2 order:2

    branch release/1.1.x order:4
    commit tag:"v1.1.0-rc.1"
    branch fix-2 order:5
    checkout fix-2
    commit id:"5"
		checkout feat-2
		commit
    checkout release/1.1.x
    merge fix-2 tag:"v1.1.0-dev.3"
		checkout feat-2
		commit
    checkout release/1.1.x
		commit tag:"v1.1.0-rc.2"
		checkout develop
		merge feat-2 tag:"v1.2.0-dev.1"
		checkout release/1.1.x
		commit tag:"v1.1.0"  id:"fix-1"
		checkout develop
		cherry-pick id:"fix-1" tag:"v1.2.0-dev.2"
		checkout release/1.1.x
		branch fix-3 order:6
		commit
		checkout release/1.1.x
		merge fix-3 tag:"v1.1.1-dev.1"
		checkout feat-2
		commit
		checkout release/1.1.x
		commit tag:"v1.1.1"
    checkout develop
		merge feat-2 tag:"v1.2.0-dev.3"

		branch release/1.2.x order:7
		commit tag:"v1.2.0-rc.1"

		checkout develop
		branch breaking-change order:3
		commit type:HIGHLIGHT
		checkout develop
		merge breaking-change tag:"v2.0.0-dev.1"

1. Use MAJOR, MINOR and PATCH as intended by Semantic Versioning.

   1. Change MAJOR on breaking changes
   2. Change MINOR on feature/fixes
   3. Change PATCH on release branch

2. Automatically create a SNAPSHOT on each PR merged to develop branch.

   1. SNAPSHOT is tagged with a v<next-version>-dev.<counter>, e.g. v1.2.0-dev.42.

   2. <next-version> is the currently developed version The logic is the same as using a -rc.x postfix, but this is called a “develop snapshot”, which should not be considered as a release candidate, but a snapshot of current state of development.

   3. <next-version> increment is a MAJOR or MINOR increment.

   4. <next-version> should be incremented as soon as a release branch is started for a current developed version

   5. <next-version> MAJOR should be incremented if a merged PR contains breaking changes.

   6. <counter> is the sequential number of the snapshot for corresponding developed version

   7. <counter> should be incremented on each commit

   8. <counter> should be start from 1 on each new <next-version>

   9. <counter> should be sequentially continued to be used in release/ branch

      <aside> ❓ To be consistent, we should be using v1.2.3-rc.4-dev.5, which should be read as “development snapshot #5 of the v1.2.3-rc.4 release”. This makes sense and corresponds to the main idea of -dev.x snapshots, but it’s quite too long for a version name.

      We could instead keep continue incrementing the <counter> in the release/ branch. But at some point this will lead to a case of switching from mobile from v1.2.3-rc4 to v1.2.3-dev.18. We wanted the version change to be obviously increasing, but I think here we lose it.

      Is this ok?

      </aside>

3. Make RELEASES when needed for desktop/mobile clients.

4. Make RELEASE CANDIDATES when needed on release/ branch.