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

Compare with Current View Page History

« Previous Version 4 Next »

Community Attendees:

Tanja de Groot Ludovic Robert Jose Luis Urien Herbert Damker Samuel Adeyemo 

Community Attendees:

LF Staff:

Casey Cain 

Agenda

DRAFT

Antitrust Policy

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

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


Meta-release status

  •  23 APIs (+2).  3 stable APIs


Multiple-API release

  • device-location will keep 3 APIs in one repo for the Fall24 release
  • 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 ?
  • make checklist for Release Managers to put in in an issue in RM repo
  • RM issue per API review which references Sub Projects  review issue(s) / release PR(s) 
  • question: would it make sense/allowed to have an additional release of the same API version in case of RM review updates for example or do we need to increase the version number in all cases ? yes, one can re-release the same API version if no changes to the yaml.

Template

  • yaml - info object / servers objects for version
  • tests
  • changlog
  • readme - enforce release naming/numbers
  • API readiness checklist

comments on content in the release PR 

  • typos
  • english

content  comments in a separate type e.g. header file example


FAQ

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)


Versioning of release management guidelines

  • Decide on the version to release the Release Management guidelines (2024-07-30)
  • 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

  •  
  • No labels