This page is to prepare the messages for the announcement of milestones or other events from the release management team.
Fall24
2024-07-1819: Reminder of M3 M3 milestone - new date: 2024-07-26 & preparation hints (to rm mailing list)
Dear all,Please be reminded
In the light of the
...
upcoming M3 milestone
...
, please find the following point to get prepared
...
:
the TSC has shifted the M3 date to 2024-07-26,but earlier is very welcome- at this date it is sufficient to have the release PR forthe API release-candidate.
- please put the link to the release PR in the (pre)-release tag field on the API release tracker when your PR is ready for review
- in this release PR you need to include:
- any updates to the readme.md as needed
- the update of the changelog.md file
- see example here: ReleaseManagement/documentation/CHANGELOG_EXAMPLE.md
HINT: create a "draft release" with GitHub to see the relevant changes since the previous version and select relevant PRs, reformulate as needed and sort them into the categories of the changelog.
- the update of the yaml file with the concerned API version and URL
A reminder that the API version (x-y-z-rc.1) is different from the release number of the pre-release (which will be r1.1).
- the update of the API readiness checklist with all required content for the release-candidate
- exceptionally, although the checklist mandates to provide the basic test cases with the release-candidate, for this first meta-release, the Sub Projects are allowed to delay these to M4. However the earlier the test cases are provided, the longer the time to actuall test any available API implementation. Please use the comment field in the checklist to indicate the delay if any. M3 will not be blocked on this point.
- do not use release branches anymore: all releases are to happen using the GitHub release feature from the main branch and setting release tags on the main branch. If this is an issue for M3, this can be resolved for M4.
- please notify the Release Management team to review the PR by adding https://github.com/orgs/camaraproject/teams/release-management_maintainers as reviewers to the release PR.
Other HINTS: (see API guidelines section 11.1)
...
- check that your servers object in the yaml looks as follows:
servers:
- url: '{apiRoot}/yourapiname/v0.yrc1 or v1rc1or v1rc1'
variables:
apiRoot:
...
description: API root, defined by the service provider, e.g. `api.example.com` or `api.example.com/somepath`
- add the following in the yaml in the info object: x-camara-commonalities: 0.4.0
example:
info:
title: One Time Password SMS
description: |-
Service Enabling Network Function API to send short-lived OTPs (one time passwords) to a phone number via SMS and validate it afterwards, in order to verify the phone number as a proof of possession.
# Relevant Definitions and concepts
- **NaaS**: *Network-as-a-Service* model where Telco Network resources are exposed to third parties through APIs. In this particular API, One Time Password is exposed following this model.
- **OTP**: *One Time password* is a one-time authorization code (OTAC) that is valid for only one login session or transaction.
# API Functionality
It enables a Service Provider (SP) to send an OTP code by SMS and validate it to verify the phone number (MSISDN) as a proof of possession.
# Resources and Operations overview
This API currently provides two endpoints, one to send an OTP to a given phone number and another to validate the code received as input.
# Authorization and authentication
[Camara Security and Interoperability Profile](https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md) provides details on how a client requests an access token.
Which specific authorization flows are to be used will be determined during onboarding process, happening between the API Client and the Telco Operator exposing the API, taking into account the declared purpose for accessing the API, while also being subject to the prevailing legal framework dictated by local legislation.
It is important to remark that in cases where personal user data is processed by the API, and users can exercise their rights through mechanisms such as opt-in and/or opt-out, the use of 3-legged access tokens becomes mandatory. This measure ensures that the API remains in strict compliance with user privacy preferences and regulatory obligations, upholding the principles of transparency and user-centric data control.
version: 1.0.0-rc.1
x-camara-commonalities: 0.4.0
termsOfService: http://example.com/terms/
contact:
name: API Support
url: http://www.example.com/support
email: support@example.com
license:
name: Apache 2.0
url: https://www.apache.org/licenses/LICENSE-2.0.html
For more examples please see OTPvalidation and
...
QualityOnDemand Sub Projects
Questions or comments ? create a a Release Mgmt issue, mail the RM mailing list or look at the FAQ - find both .
The links to the latter 2, and more generally on the API release process, are on the RM wiki and in GitHub.
Thanks !
The CAMARA Release Management team
...