Figure out tagging [versioning?] strategy

[patcon]

Re-ticketed from https://github.com/pol-is/polis-deploy/issues/8#issuecomment-612927970

@crkrenn had some suggestions in the above ticket.

:dart: Success criteria: We have a tagging strategy and it's documented somewhere. (sound ok?)

[patcon]

I'm personally not feeling urgency on this, but think it's great if others want to hash it out sooner :)

I'll be interested to have tagging sorted once we have a docker build-server (https://github.com/pol-is/polisServer/issues/67) running, where the tags will be used to make installable images.

Open questions:

• are we versioning for the whole app as one? or will we keep versioning per-component (server, clients with own package.jsons? or somehow version both the parts and the whole?
• do we version the server with its API separately, since that can be more predictably following semver?

Related: https://github.com/semver/semver/issues/161

---

Another suggestion is to couple this "tagging strategy" with discussing/documenting how we manage a future changelog. Might be nice to have that sorted before we start tagging things. But happy to keep that convo separately, or have it later.

Ref: https://keepachangelog.com/en/1.0.0/

[patcon]

Potential dup: https://github.com/pol-is/polis-issues/issues/66

[patcon]

monorepo changes versioning/tagging considerations.

• https://github.com/lerna/lerna#how-it-works
  • though lerna is for JS-only, it helpfully explains two different monorepo versioning tactics: fixed vs independent
• https://github.com/ethereum/js-organization/issues/8
  • discussion above not yet put into practice by that project
  • summary: suggests separately namespaced tags (independent approach), naming like so in git tags:
    • @pol-is/[email protected]
    • @pol-is/[email protected]
    • @pol-is/[email protected]
• alternatively: could just version the root project for now ("fixed" approach), and worry about components later.
  • maybe just bump the minor version every 2 weeks or so, and not really focus on the major version. So if we start at 2.0.0 as x.y.z, then every two weeks we tag a new one (2.1.0, 2.2.0, ... 2.123.0, ...), and so a build server will create docker tags according to that. We could ignore major versions (x) and patch versions (z) for now, and essentially treat minor versions (y) as build numbers, at least until we have a need for something more complicated.

[crkrenn]

+1 on the fixed approach.

If it is not hard to bump the patch version regularly, I would suggest starting with 2.0.0 ... 2.0.27 for the dev branch.

When we get to the point where we are considering merging dev into master, one strategy is to create a preprod branch 2.2.0, retag the dev branch 2.3.0, iterate on testing and bugfixes on preprod until it can become master.

We can do something simpler, but starting with 2.0.X tags for the dev branch would provide some flexibility.

Prod	Preprod	Dev	comment
1.0.0		2.0.0	start
1.0.0		2.0.7	develop
1.0.0		2.0.47	develop
1.0.0	2.2.0	2.3.0	prepare for deployment
1.0.0	2.2.3	2.3.7	refine deployment; continue development
1.0.0	2.2.11	2.3.25	refine deployment; continue development
2.2.11	deleted	2.3.43	deploy; continue development
2.2.14		2.3.73	bug fix on production; continue development
2.2.14	2.4.0	2.5.0	prepare for deployment
2.4.7	deleted	2.5.27	deploy