Release Strategy for Discussion

At the GS Specification level, we can define our own versioning - owned by product committee?

Major = tbd…

Minor = wip…

Patch = almost…

In the BB’s we’ve got to adhere to SEMVER if we want anyone to contribute. Each time we bump a version they’ll want the tests to run. SEMVER:

Major.Minor.Patch

GovStack Releases (for example)
- 2.0
  - Target Date: July 2023
  - Key Use Cases:
    - a
    - b
    - c
  - Building Blocks:
    - infomed: 2.0
    - registries: 3.1
    - workflow: 19.23.1144
- 1.1.0 or “GS 2021” or “GovStack BLUE!” or “GovStack GREEN!”
  - Info-med: 1.3.0
  - Workflow: 1.2.0
  - Registries: 1.3.0
  - Payments: 0.9.0
- 1.0.0
  - Info-med: .9.0
  - Workflow: 0.9.1
  - Registries: 0.9.0

TD & Wes to discuss “sandbox” - what does the vendor that just got contracted to build think they’re building?

is it tooling to “do deployments” - this is what the tech committee has focused on.
- infrastructure?
- terraform and ansible scripts?
- the examples/ dir in each BB repo
or is it a long-running/standing deployment
- taylor thinks it’s this and he disapproves of it.
- wes thinks it’s the first one, and taylor hopes he’s right!

GovStack Deployments
- UKRAINE-SANDBOX-0.1.0
  - ???
- THE-SANDBOX-2.0
  - GS-VERSION: 1.1.0
  - Building Blocks:
    - x
    - y
    - z
    - a
- THE-SANDBOX-1.0
  - GS-VERSION: 1.1.0
  - Building Blocks:
    - x
    - y
    - z
- POST-PARTEM-2.0
  - GS-VERSION: 1.1.0
  - Building Blocks:
    - Info-med:
      - Example: X-Road
    - Registries:
      - Example: eReg from UNCTAD
- PAYMENTS-WB-1.0
  - GS-VERSION: 1.1.0
  - Info-med:
    - Example: X-Road
  - Registries:
    - Example: eReg from UNCTAD
  - Payments:
    - Example: MPESA
- POST-PARTEM-1.0
  - GS-VERSION: 1.0.0
  - Building Blocks:
    - Info-med:
      - Example: X-Road
    - Registries:
      - Example: eReg from UNCTAD