Release r3.2 (Fall'25 M4)

[albertoramosmonagas]

What type of PR is this?

Add one of the following kinds:

• subproject management

What this PR does / why we need it:

Publication of Fall'25 M4 public release of population-density-data v0.3.0

Which issue(s) this PR fixes:

Fixes #102

Special notes for reviewers:

None

Changelog input

 release-note
Publication of Fall'25 M4 public release of population-density-data v0.3.0

Additional documentation

None

[hdamker]

@albertoramosmonagas here is the list of changes since r3.1 if you would create a draft release:

What's Changed

• Chore: Reset version numbers to wip following r3.1 by @eric-murray in Chore: Reset version numbers to wip following r3.1 #92
• Fix indentation and multiple blank line linting errors in feature files by @eric-murray in Fix indentation and multiple blank line linting errors in feature files #96
• Rebase linting branch to main by @eric-murray in Rebase linting branch to main #97
• fix: solve problem with scneario size and name length by @albertoramosmonagas in fix: solve problem with scneario size and name length #101
• admin: migrate to centralized linting workflows by @hdamker-bot in admin: migrate to centralized linting workflows #95
• Alignment with Commonalities r3.3 by @albertoramosmonagas in Alignment with Commonalities r3.3 #94

New Contributors

• @eric-murray made their first contribution in Chore: Reset version numbers to wip following r3.1 #92

Please select the relevant ones and combine with the change(s) within r3.1.

And please merge main into your release branch, so that it is up-to-date with main (that's the reason I have set the PR to draft for now).

[albertoramosmonagas]

combine with the change(s) within r3.1.

Thanks for the summary. I’ve already included all the changes listed since r3.1 in the draft changelog for r3.2.

Just one quick clarification: when you mention “combine with the change(s) within r3.1”, I assumed those remain part of the previous r3.1 release and didn’t carry them over into r3.2. Would you expect the r3.1 changes to be repeated in the r3.2 changelog as well? I’m happy to adjust if needed, just want to make sure we’re on the same page.

Regarding main, this release branch was originally created from it and is already fully up to date. Not sure if there’s anything else I should do on my side in that regard — happy to double-check if needed.

[hdamker]

combine with the change(s) within r3.1.

Thanks for the summary. I’ve already included all the changes listed since r3.1 in the draft changelog for r3.2.

Just one quick clarification: when you mention “combine with the change(s) within r3.1”, I assumed those remain part of the previous r3.1 release and didn’t carry them over into r3.2. Would you expect the r3.1 changes to be repeated in the r3.2 changelog as well? I’m happy to adjust if needed, just want to make sure we’re on the same page.

From the template for CHANGELOG.md:

The below sections record the changes for each API version in each release as follows:

• for an alpha release, the delta with respect to the previous release
• for the first release-candidate, all changes since the last public release
• for subsequent release-candidate(s), only the delta to the previous release-candidate
• for a public release, the consolidated changes since the previous public release

In your case: the section for r3.2 should contain all changes since the last public release (r2.2). In the "Full Changelog" line this is already correct (...compare/r2.2...r3.2)

Regarding main, this release branch was originally created from it and is already fully up to date. Not sure if there’s anything else I should do on my side in that regard — happy to double-check if needed.

No, the release branch is 13 commits behind camaraproject:main (reason is that also the main branch in your fork is behind the upstream repository, you would have needed to sync it before creating the branch):

Just click on the these "13 commits behind" and you will get offered to create a pull request from camaraproject:main into your PR branch. This PR you can merge directly yourself (as the PR branch is not protected) and you are done.

[albertoramosmonagas]

Hi @hdamker,

Thanks a lot for the explanation. From VSCode everything appeared to be fully up to date, so I hadn’t noticed anything pending. But after checking directly on the fork, I did see it was indeed behind main as you pointed out. I hadn’t received any notification or prompt about that.

I’ve now synced it and I believe everything should be in order. Let me know if there’s anything else you’d like me to double-check.

[hdamker]

@albertoramosmonagas Thanks for the updates. I suppose that the PR is now "ready for review" and will change the status accordingly.

[Kevsy]

As well as the release-management review comments above, two additional changes to make in population-density-data.yaml:

L5: In the info.description please start the first sentence with 'The' to be consistent with the marketing description on the wiki (i.e. 'The Population Density API')

L317: you have correctly referenced the RFC for the date-time format, but you need to delete the additional text

Recommended format is yyyy-MM-dd'T'HH:mm:ss.SSSZ
(i.e. which allows 2023-07-03T14:27:08.312+02:00 or 2023-07-03T12:27:08.312Z)
The minimum startTime must cover at least 3 months before the request time."

...as per camaraproject/Commonalities#497

[albertoramosmonagas]

L5: In the info.description please start the first sentence with 'The' to be consistent with the marketing description on the wiki (i.e. 'The Population Density API')

Hi,

Thanks for the comments. The issue at L5 is now fixed — the description starts with “The Population Density API” to align with the marketing description on the wiki.

For L317, I suggest another solution would look like this

Start date time. It must follow [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) and must have time zone. The minimum startTime must cover at least 3 months before the request time.

This removes the additional text about the recommended format, as per camaraproject/Commonalities#497.

Could you please confirm this approach is fine? If so, I will apply it consistently across the rest of the spec

[Kevsy]

Hi @albertoramosmonagas ,

The issue at L5 is now fixed
Thanks!

This removes the additional text about the recommended format, as per camaraproject/Commonalities#497.

That PR also removes the text The minimum startTime must cover at least 3 months before the request time.., so that would mean this API was not following Commonalities. It would also mean additions in the Gherkin .feature to cover the compliant/non-compliant start times.

Could this be covered in the info.description as a recommendation?

[albertoramosmonagas]

Hi @albertoramosmonagas ,

The issue at L5 is now fixed
Thanks!

This removes the additional text about the recommended format, as per camaraproject/Commonalities#497.

That PR also removes the text The minimum startTime must cover at least 3 months before the request time.., so that would mean this API was not following Commonalities. It would also mean additions in the Gherkin .feature to cover the compliant/non-compliant start times.

Could this be covered in the info.description as a recommendation?

Changes applied.

[jgarciahospital]

LGTM

[albertoramosmonagas]

@camaraproject/population-density-data_codeowners
🎉 No critical issues found - API is ready for release! - #317

[Kevsy]

Approved on behalf of Release Management 👏

Next steps for the team:

• PR merged (by API repository codeowner)
• Release created within GitHub (by API repository codeowner)
• Release Tracker updated (with creation date of the release and the release tag link)