Prepare API location-retrieval version 0.3.0-rc.1

[bigludo7]

What type of PR is this?

Add one of the following kinds:

• documentation
• subproject management

What this PR does / why we need it:

Generation of first release-candidate for location-retrieval API

This first release candidate r1.1 contains the definition and documentation of the release-candidate of the location-retrieval API v0.3.0-rc.1.

Which issue(s) this PR fixes:

Fixes #

Special notes for reviewers:

Changelog input

 release-note

Additional documentation

This section can be blank.

docs

[jlurien]

@bigludo7 Versions for RC according to https://wiki.camaraproject.org/display/CAM/API+versioning

[maxl2287]

The API Readiness Checklist is mentioning v0.2, but here we have v0.3.
Maybe update this also?

https://github.com/camaraproject/DeviceLocation/blob/main/documentation/API_documentation/location-retrieval-API-Readiness-Checklist.md

[hdamker]

@jlurien @bigludo7 Here we have a challenge: if there are multiple API within a repository, it isn't possible to just release one of it ... as the tag/release is always for the complete repository. Or as it is noted within https://github.com/camaraproject/ReleaseManagement/blob/main/documentation/API_Release_Guidelines.md "A GitHub release shall not include any wip API versions" and "update of the version information in the API OAS definition files (no "wip" in the version field and base URL of any of the API files)"

What would be possible is a mix of rc version (of location-retrieval) and alpha versions (or the others) within the same release.

If you want to release in different pace beyond that you need to split into own repositories.

[bigludo7]

The API Readiness Checklist is mentioning v0.2, but here we have v0.3. Maybe update this also?

https://github.com/camaraproject/DeviceLocation/blob/main/documentation/API_documentation/location-retrieval-API-Readiness-Checklist.md

The API Readiness Checklist is mentioning v0.2, but here we have v0.3. Maybe update this also?

https://github.com/camaraproject/DeviceLocation/blob/main/documentation/API_documentation/location-retrieval-API-Readiness-Checklist.md

Yes thanks ! updated

[bigludo7]

@jlurien @bigludo7 Here we have a challenge: if there are multiple API within a repository, it isn't possible to just release one of it ... as the tag/release is always for the complete repository. Or as it is noted within https://github.com/camaraproject/ReleaseManagement/blob/main/documentation/API_Release_Guidelines.md "A GitHub release shall not include any wip API versions" and "update of the version information in the API OAS definition files (no "wip" in the version field and base URL of any of the API files)"

What would be possible is a mix of rc version (of location-retrieval) and alpha versions (or the others) within the same release.

If you want to release in different pace beyond that you need to split into own repositories.

Thanks Herbert
I think we have to split in several repos. The question is when we have to do this? If we have to do it before M4 this is challenging - if we have till M5 that provide us more time.

[hdamker]

@bigludo7

I think we have to split in several repos. The question is when we have to do this? If we have to do it before M4 this is challenging - if we have till M5 that provide us more time.

If I look on https://wiki.camaraproject.org/display/CAM/DeviceLocation+API+Release+Tracking you want to have all three APIs within the Fall24 release ... then should it be possible to release them together until the meta-release.

Between M4 and M5 is definitely no option to do the change, if you want to do it for the current release cycle now is more or less the last point in time. Otherwise in the next release cycle.

[jlurien]

I think we can manage to have the 3 APIs in RC by M3 (with different versions) and then add the r1.1 tag. For this meta-release we plan to release new versions of the 3 APIs so it is manageable, with some sync. We have to wait to geofencing to have the rc ready. I hope that we can have the first RC by next meeting.

After this meta-release we may think in splitting the family to gain some flexibiity. wdyt?

[bigludo7]

I think we can manage to have the 3 APIs in RC by M3 (with different versions) and then add the r1.1 tag. For this meta-release we plan to release new versions of the 3 APIs so it is manageable, with some sync. We have to wait to geofencing to have the rc ready. I hope that we can have the first RC by next meeting.

After this meta-release we may think in splitting the family to gain some flexibiity. wdyt?

If we are able to do this this is very good for me !
It means that we have one README (instead of 3), one CHANGELOG (instead of 3) and one checklist (instead of 3). Correct?

[jlurien]

I think we can manage to have the 3 APIs in RC by M3 (with different versions) and then add the r1.1 tag. For this meta-release we plan to release new versions of the 3 APIs so it is manageable, with some sync. We have to wait to geofencing to have the rc ready. I hope that we can have the first RC by next meeting.
After this meta-release we may think in splitting the family to gain some flexibiity. wdyt?

If we are able to do this this is very good for me ! It means that we have one README (instead of 3), one CHANGELOG (instead of 3) and one checklist (instead of 3). Correct?

I guess so but let's get the confirmation from RM team

[hdamker]

If we are able to do this this is very good for me ! It means that we have one README (instead of 3), one CHANGELOG (instead of 3) and one checklist (instead of 3). Correct?

I guess so but let's get the confirmation from RM team

As discussed in https://wiki.camaraproject.org/display/CAM/2024-07-23+Release+WG+Minutes:

• one README.md
• one Changelog (but sections for each API in there)
• but 3 checklists (one per API)

Regarding CHANGELOG and README you can have a look on camaraproject/DeviceStatus#190 to get an idea.

[hdamker]

@jlurien The release PR for r.1.1 which release management can review must be one which:

• includes the changelog entry (for all contained APIs)
• the readme updates
• the final update of the checklists (if any)
• and most important: sets the API versions and paths within the YAML files of all three APIs to the the one which will released

The release PR should contain no further content changes, especially in the code of YAMLs and .feature files - they should be done within previous PRs. That is not the case here, but in #241.

My proposal: focus this PR here on the needed changes of location-retrieval (e.g. rename to "Prepare API location-retrieval version 0.3.0-rc.1", but leave (or even set) the version to "wip".

[jlurien]

Converto to "Prepare API location-retrieval version 0.3.0-rc.1" as suggested by @hdamker

[jlurien]

I think license has to be included