Agenda

Antitrust Policy

• Agenda Review

• Action Items Review: Release Management Working Group - CAMARA Project - Confluence

• Open Issues Review: Issues · camaraproject/ReleaseManagement (github.com)

• Meta-release status: Meta-release Fall24 - CAMARA Project - Confluence

• Multiple-API repo release

• API reviews - practicalities

• FAQ additions

• Versioning of release management guidelines

• Vacation schedule (reminder)

Minutes

Action Items Review

• Missing release manager will handicap M3 milestone reviews - need for distribution and automation. Risk on the Meta-release date.

• add a backlog issue on linting rules for RM and other guidelines

Open Issues Review

Add team release-management_maintainers to all sub project with read access in order to allow Sub Projects to mention the team wg management
#43 opened 18 hours ago by hdamker

Clarification on release tag and version naming for Commonalities and ICM documentation

#41 opened last week by rartych

• RM team suggest to update the ICM release tag name at the next release. linked to ICM release plan issue done.

Update links in README.md file documentation

#40 opened 3 weeks ago by tanjadegroot -

API Versioning - Aggregation backlog question release management

#14 opened on Jul 6, 2023 by chrishowell

• backlog item

Meta-release status

•  23 release-candidate APIs (+2).  3 stable APIs

Multiple-API repo release

device-location sub Project will keep 3 APIs in one repo for the Fall24 release. After it may be split. The question is how to handle the release management.

Answers:

• see CHANGELOG and Readme examples in device-status PR#190

• should not have any wip API version 

• One changelog

• one readme

• 3 release trackers (one per API)

• 3 API readiness checklists

• the final release PR should do ONLY update wip to version and documentation updates

• to check links, create a (test)branch with the release tag name  (and then remove the branch)

M3 API reviews - practicalities

• how to distribute work - proposal to use a Sub Project issue in which to track what is reviewed and by whom ?

• RM issue per API review which references one or more review issue(s) / release PR(s) of the Sub Project

• question: would it be allowed to have an additional release of the same API version in case of RM review updates for example ? yes, one can re-release the same API version if no  or only patch changes to the yaml content were done. (typos, english, etc).

Review issue template

• yaml - info object / servers objects for version

• tests

• changelog

• readme - enforce release number and API version naming.

• API readiness checklist

comments on content in the release PR can be on 

• typos

• english

content related comments encountered during the review should be done in a separate issue, for example header file schema example (putting parameters in headers in a get operation for security instead of using a POST - may need further guidelines, and possibly definition of common schema definition for header parameters.

FAQ additions

What to do if I accidentally released my API before Release Management check ?

You can easily create a next release rx.y+1 at any time. 

In this case, create a "Release Management review" issue in your Sub Project and assign it to a release manager (tanja, samuel, herbert, jose luis, rafal) 

If there is a change required, this will be put in the comments in the issue and the Sub Project team can start a new PR to include the changes.

NOTE: If there are substantial change the version should go back to wip in a dedicated PR and release later. If it concerns content changes to the API yaml file, then also the API version should be increased in-line with the type of change (most likely MINOR ot PATCH).

The Sub Project can decide when to merge the PR and create the new release.

What to do in case of codeowner absence (only during holidays) ?

You should have at lease 2 or preferably 3 codeowners

However in case of issues, if consent of the team seems OK, an admin can do a merge (email: adm@camaraproject.org)

HINT: How do I check that links in my Sub Project are defined correctly ?

To  check links in the repo, create a (test)branch, tag it with the targeted release tag name.

It will give errors if links are not aligned. Then delete the (test)branch.

Update the links latest in the release PR.

Versioning of release management guidelines

• Proposal to do r0.1.0  (no alpha/release-candidate approach).

Vacation schedule:

• Samuel: Aug 7-14th

• Tanja: Aug 5-30th

• Rafal: Aug 12-16 + other tbd

• Casey:  first week of Sep

• Herbert: not fixed yet

Action items