Skip to content

Conversation

@albertoramosmonagas
Copy link
Contributor

What type of PR is this?

Add one of the following kinds:

  • correction

What this PR does / why we need it:

Delete the additional text for RFC date time format.

Which issue(s) this PR fixes:

Related comment: link

Special notes for reviewers:

Only a typo that was missed in the release management review has been modified, and we do not see the need to create a new version of the API for this.

Changelog input

 release-note
Solve typo on the additional text for RFC date time format

@jgarciahospital
Copy link
Collaborator

@Kevsy may we just merge the typo and re-arrange the release?

@Kevsy
Copy link
Contributor

Kevsy commented Sep 10, 2025

Only a typo that was missed in the release management review has been modified, and we do not see the need to create a new version of the API for this.

OK, I see what has happened: this was raised in the release management review here, with the codeowners agreeing that the change needed to be made (i.e. removing all additional text as per the Commonalities PR).

Commit ff0bec9 then suggested that it had been done, but I can see now that only part of the unnecessary text was removed in that commit, and for only one instance of date-time. My apologies for missing that.

@Kevsy may we just merge the typo and re-arrange the release?

Let me check. There is a way on the CLI to apply the release tag to a given commit, but I'm not sure how that is done via the Web interface.

@Kevsy
Copy link
Contributor

Kevsy commented Sep 10, 2025

HI @albertoramosmonagas @jgarciahospital - release management have discussed and decided there is no urgent need to remove the additional sentences, following the guidance on the the wiki page for 0.6.0

Additional sentence can be removed, but can stay as non-mandatory text in the description of string parameter with date-time format

So the issue/PR should be done in next release.

@albertoramosmonagas
Copy link
Contributor Author

Hi @Kevsy, thanks for the clarification.

We’ll leave the PR in draft status and with this comment we indicating that it falls outside the scope of Fall25.

@albertoramosmonagas albertoramosmonagas marked this pull request as draft September 10, 2025 12:51
@hdamker
Copy link
Contributor

hdamker commented Sep 10, 2025

There is a way on the CLI to apply the release tag to a given commit, but I'm not sure how that is done via the Web interface.

Just a reminder:

Regarding moving release tags: While it's technically possible to delete and recreate a tag on a different commit using the CLI, this isn't supported directly through GitHub's web interface—and for good reason.

Important note: Rewriting release history by moving tags is strongly discouraged as it can cause issues for users who have already pulled the release. Once a release tag is published, it should be considered immutable.
Best practice: When a bug is discovered after a release, the standard approach is to:

Leave the existing release tag in place
Fix the bug in a new commit
Create a new patch release (e.g. here r3.3)

This is exactly why we emphasize thorough review before creating a release. 😊 In this case, since the fix isn't critical and can wait, we are good.

cc: @camaraproject/release-management_reviewers

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.

4 participants