...
Y = minor version, substantial changes based on feedback, changes with smaller side-effects, API changes required to be non-breaking.
Z = patch version, small changes, additions without side-effects, typos etc, may be released outside of a full review process
...
The same project may have workflows in different systems, which thus have separate release cycles that are periodically synchronized.
For instance:
Workflow | Git | Comment | |
Definition doc draft | govstack-bb-consent-specification-1.0.0-draft1 | Using the “draft” suffix, we tag versions in GitBook that are signed off by the WG. For instance to pass on for internal review. | |
Definition doc review release | govstack-bb-consent-specification-1.0.0-rc1 | Specification releases signed off by product owner. | |
Definition doc review | govstack-bb-consent-specification-1.0.0 | Finally, we release a “stable” document without the draft/rc suffix. | |
Definition doc feedback processing | govstack-bb-consent-specification-1.0.1 | During a rapid processing of review feedback, we may wish to indicate updates by bumping the patch version each time, making the changes visible to review panelists. | |
Release for POC | This document will have SRS level detail with proven POC | ||
Product level version | Same BB may be be used in different products, with different customization | ||
Country level version | Same product may be used in different countries with different customization |
Release process (WIP)
It is noted that many people will have access to suggest changes, implement changes and tag versions. The following release process should be followed with respect to version numbering:
...