...
2) The proposal is to
- develop only one API (file) (exception see below) in an one API Sub-projectProject
- group APIs API Sub-projects for meeting / governance purposes (ex-API families) outside of the API Sub-projects, e.g.: .
- options are
- using a GitHub Working Group folder - but this is being restructure as we speak)folder
- using a CAMARA Wiki page . - seems to be the preferred preferable approach as this is also where meetings are now being managed.
- exception: if an API Sub-project wants to keep multiple APIs in the same API Sub-project:
- all APIs in this API Sub-project shall have the same version and shall always be released together.
- the API Sub-project name shall be used instead of the API name in the creation of the API version release assets
- if any of the APIs needs to evolve its version to a different version than the other APIs in the same API Sub-project, it shall be moved (with its related assets) to its own API Sub-project.
NOTE: We can look at reworking/simplifying the API sub-project repository structure if needed.
...
- 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 subAPI Sub-project creation to ???cCasey & Evan
- on the API Sub-project pages on the wiki add the list of APIs managed together
- Update their wiki page to list the APIs they have release and are maintaining.
...
- together
- Create one API release tracker page for each API-Subgroup and its API(s)
Need to check Herbert's proposal here: Proposal to establish API Families as Working Groups across API Sub Projects · Issue #7 · camaraproject/ReleaseManagement (github.com)
...