...
NOTE: We can look at reworking/simplifying the API sub-project repository structure if needed.
Agreement from the team to adopt the "1 API per repo" approach in principle but also more flexibility is introduced by adding the next proposal.
2024-04-12: Additional proposal from Herbert/Shilpa on API version asset naming to to decouple release name/number from contained API versions
- Decouple the (pre-)release tag and package name/number from the API version.
- Add some addition semantics in the release name/number
See whiteboard session below for examples.
Proposal:
- a) Tag, release and repo are coupled
- b) Release name/number is decoupled from API version
- Number the releases rx.y; Use r0.y if an API is sandbox-grade and rx.y with x>0 once in meta-release.
- Use subsequent numbering of releases across meta-releases (see whiteboard example below).
Agreement from the group team to go forward with that decoupling proposal and update the process to reflect it (@ Tanja)
2024-04-12: Additional proposal of meeting participants:
- option b) use another naming/numbering schema for the releases of the sub project repositories (note tdg: not sure I understand if this is different from the proposal on the table "rx.y" ?)
2024-04-12: Additional proposal from Herbert to introduce beta releases
In this case:
- an initial or alpha release is for rapid development
- a beta release is stable enough for API implementation & testing
- a release-candidate only allows for bug fixing
Agreement from the team not fully clear, but will do an update to the process to reflect it (@ Tanja)
...
- Each API Sub-projects that contain multiple APIs should
- decide if it should create separate sub-projects for its APIs
- If so, decide on the name and request the API Sub-project creation to cCasey & Evan
- on the API Sub-project pages on the wiki add the list of APIs managed together
- Create one API release tracker page for each API-Subgroup and its API(s)
Decision point:
- a) Tag and repo are coupled, but decoupled from API version(s) contained in the release
- b) Release name/number is decoupled from API version - just number the releases e.g rx.y and use x=0.y if API not stable;0) once in meta-release. use subsequent numbering across meta-releases
...
WISHLIST
- ability to create the API release tracker page data by reading a yaml file in the repo. Tanja de Groot to investigate - aother are welcome to do so too :-)
Whiteboard example
Potential release sequence for a new project:
r0.1 (pre(release tag only, no release package (repo zip))
- api1 with v0.1.0-alpha.1
r0.2 (release tag only, no release package (repo zip))
- api1 v0.10-alpha.2
- api2 v0.1.0-alpha.1
r0.3 (pre-release) => API implementation for testing - multiple beta releases following feedback
- api1 v0.10-beta.1
- api2 v0.1.0-beta.1
r0.4
r0.5 (latest)
- api1 v0.1.0
- api2 v0.1.0
...