Skip to content

Release Review: DeviceMediaStreamingRate r1.1 (alpha) - #35

Open
camara-release-automation[bot] wants to merge 4 commits into
release-snapshot/r1.1-235132ffrom
release-review/r1.1-235132f
Open

Release Review: DeviceMediaStreamingRate r1.1 (alpha)#35
camara-release-automation[bot] wants to merge 4 commits into
release-snapshot/r1.1-235132ffrom
release-review/r1.1-235132f

Conversation

@camara-release-automation

@camara-release-automation camara-release-automation Bot commented Jul 17, 2026

Copy link
Copy Markdown
Contributor

Release Review: r1.1 alpha

This PR finalizes the reviewable release content for the active snapshot.

Edit and review this PR before merging it into the release snapshot. After Codeowner and Release Management approval, merging this PR creates the draft release.

Release contents

API Version Status Comparison target
media-streaming-rate 0.1.0-alpha.1 alpha N/A

Dependencies: Commonalities r4.3, ICM r4.2

Codeowner Actions

Tick each box once done. Ticking the last box — "The release is ready for Release Management review" — starts the Release Management review.

  • Update the CHANGELOG

    What to do:

    • Copy all API-consumer-relevant changes from the provided list into the appropriate Breaking changes / Added / Changed / Fixed / Removed sections for each API. List breaking changes both in Breaking changes and in their normal change category.
    • Do not copy administrative, tooling-only, or internal maintenance changes unless they affect API consumers.
    • For each API, fill the CHANGELOG against the stated comparison target, following the release-type rules at the top of the CHANGELOG.
  • Document deferred validation warnings (and hints)

    What to do:

    • Check the CAMARA Validation comment on this PR for warnings and hints.
    • For each warning you do not fix, document it in an issue: include a copy of the validation summary line(s) and the reason the fix is deferred.
    • Document in the same way any validation hint that is applicable to the API and needs to be fixed later.
    • You may group several findings into one issue or split them across issues — either is fine.
    • List the documenting issue(s) in a comment on this PR.
    • Note: documenting deferred warnings is optional but recommended for alpha pre-releases, and mandatory for rc pre-releases and public releases.
  • The release is ready for Release Management review

    Check that:

    • All mandatory release assets for the declared status(es) are present (see the table below "Required release assets per API status" by expanding the arrow);
    • API documentation and test cases are adequate for the target status.

    Tick this box to confirm readiness and to start the Release Management review.

Release Management Actions

The following actions and checks are done by a Release Management reviewer before approving the PR:

  • Assign the Release Management reviewer(s) as assignee(s) of this PR
  • CHANGELOG follows the release documentation rules
  • Breaking changes are documented and version updates follow SemVer rules
  • Mandatory release assets are present for each API according to its status
  • All remaining validation warnings are documented in issues and the reasons for deferral are defensible
Required release assets per API status
Nr Asset alpha rc initial
public
stable
public
1 Release Plan M M M M
2 API Definition(s) M M M M
3 Commonalities compliance O M M M
4 API Documentation M M M M
5 User Stories O O O M
6 Test Cases (basic) O M M M
7 Test Cases (enhanced) O O O M
8 API Description O O M M

M = Mandatory, O = Optional — Full documentation

Valid next actions for codeowners

  • Merge this PR when all Codeowner Actions and Release Management Actions are complete and the required approvals are present — creates the draft release
  • Use /discard-snapshot <reason> in the Release Issue to discard this snapshot, return to planned, and update content on main

Snapshot: r1.1-235132f

@camara-validation

camara-validation Bot commented Jul 17, 2026

Copy link
Copy Markdown

CAMARA Validation — PASS (with warnings)

0 errors, 1 warnings, 2 hints | Profile: standard

View full results

Warnings SHOULD be documented in one or more issues before this release — see the Codeowner Actions in the PR description.

@maheshc01

Copy link
Copy Markdown
Contributor

@eric-murray thank you for helping me the updates!

@tanjadegroot we have followed all the steps you had recommended and its complete now. requesting for your or @camaraproject/release-management_reviewers review and feedback.

@Kevsy Kevsy self-assigned this Aug 20, 2026
@Kevsy

Kevsy commented Aug 21, 2026

Copy link
Copy Markdown

@maheshc01 @maxl2287 @sachinvodafone please take a look at the release review issue tracker #37 which has all the sub-issues inside.

EDIT 25th August: The main one is #38 which could be a blocker (not sure as this is an alpha) None of the issues listed are blockers for the alpha but will need to be addressed for the initial release.

Meanwhile please just check the suggestion raised in the review below.

Comment thread CHANGELOG/CHANGELOG-r1.md Outdated

@Kevsy Kevsy left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just the suggestion to expand the CHANGELOG entry to include the original PR text and link. Once done I can approve on behalf of release management. Issue to consider for the initial release are collected in #37

Co-authored-by: Kevin Smith <Kevsy@users.noreply.github.com>
@maheshc01

Copy link
Copy Markdown
Contributor

Hi @Kevsy have accepted you change in the changelog. thank you for the suggested update.
Requesting for the approval of alpha release.
As recommended we will address the remaining open items in the initial release.

@hdamker

hdamker commented Aug 28, 2026

Copy link
Copy Markdown
Contributor

As recommended we will address the remaining open items in the initial release.

@maheshc01 Please plan for a release candidate which will ideally also incorporate the changes coming with Commonalities r4.4 (expected about next week). The goal is that there are no changes and fixes between the last release candidate and the public release needed. A release candidate is meant to give interested stakeholders, implementators and the CAMARA community time to report any issues they see, so there should be minimum time between the last rc and the public release (four weeks are recommended).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants