Release Strategy for Discussion
- Taylor Downs
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
Major = breaking change (backwards incompatible)
Minor = new feature added
Patch = fix to current thing, non-breaking
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