Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

This page holds proposals for new GitHub issues in the Release Management repo.

Proposals to close the existing issues are provided here: Open Issues Consolidated

Multiple APIs in one API Sub-project

Issue: 

GitHub release packages include the full API Sub-project.

If multiple API files are managed in one API Sub-project, then release package will include all APIs.

Proposal:

1) The notion of API family will not be release managed. CAMARA release management only considers APIs.

2) The proposal is to

  • develop only one API (file) (exception see below) in one API Sub-Project
  • group API Sub-projects for meeting / governance purposes (ex-API families).
  • options are 
    1. using a GitHub Working Group folder 
    2. using a CAMARA Wiki page - seems to be the 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.

Impact on Wiki, could be either:

  • Add the API groupings on the API Sub-group page

API Groupings:

The grouping of APIs into families or other groupings, e.g. by related working groups, can be done easily using a CAMARA wiki page.

This will reduce the number of meetings and reporting load with the increasing number of APIs, and facilitate moving APIs from one family or group to another, or combining APIs from multiple families into into into family.

Actions:

  • 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)

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)




  • No labels