With conventional commit, you can also reference issues with Refs: #1234. This does not seem to have been considered.

In the Conventional Commit Specification, it only defines the authorized existence of footers, excerpt:

• One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a : or # separator, followed by a string value (this is inspired by the git trailer convention).

• A footer’s token MUST use - in place of whitespace characters, e.g., Acked-by (this helps differentiate the footer section from a multi-paragraph body). An exception is made for BREAKING CHANGE, which MAY also be used as a token.

• A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.

The examples used in the specification do use the Refs: git trailer to define issue examples, however, none of the current Team Version Control System (VCS) Servers (Github, GitLab, Gitea, BitBucket) recognize refs as a defined git trailer or syntax to close an issue automatically upon push or merge of that commit to the default branch. That is where I came up with the authorized git footer list to extract issue references. In PSR's custom template, I use the linked_issues to add a closure reference into the CHANGELOG and I deliberately left off ref: because then I had a way of still adding a reference for why this commit was being made without closing it or marking it as closed in the CHANGELOG. The ref git trailer, I feel is useful for incremental adjustments while the others are helpful for when the issue is complete.

The next goal is to use the linked_issues to write a comment on those issues about the release that has been made (see #975). This would be broken with the use of ref especially if the issue was not auto-closed because the VCS does not interpret that, although you could argue that PSR currently supports a superset of closing git footers beyond what the team VCS's currently support individually. PSR's is also a bit more flexible for multiple issue specification that is not supported by most VCSs.

An alternative implementation?

Add ref and separate out the linked_issues from closed_issues on the commit object. Then, for #975, only write a release note on the closed_issues and use the Team VCS API to auto close the issue if it isn't already. The second part of this is to handle the superset problem when the Team VCS in use doesn't support that git trailer type but PSR does.

Separately, you did not update the unit tests or documentation so don't mark off the PR completion checklist until you have.

Hi
I understand your idea, to create two lists, one with linked issues and another with closed ones.

So, I understand that linked_issues should show all of them, and then closed_issues should only show those that would be closed.

My response was more of a question of an alternative because your current solution would break the roadmap I had for the future. Are you trying to use linked_issues using the refs in your changelog? Otherwise what is the intent for reading refs?

Yes, I'm trying to read it because what I wanted was to put in each commit the task that had led to adding that change.

Ok, so with that in mind likely linked_issues should be a superset of closed_issues that way for your changelog you are iterating through linked_issues for those references. But for the future auto closing of issues, then PSR would iterate through closed_issues

Yeah, I think that would be the best way for customers to complete the changelog correctly and then be able to add that automatic closing functionality.

I have uploaded the adapted tests and different types of refs that could be used.

Should I add closed_issues to this PR? Or should this go in another one?

A separate PR likely makes sense for the closing issues part. Thank you.

And so would the PR be valid, or would some change need to be made?

Hi @codejedi365
Do you need me to change anything else?

Sorry I've been unavailable. I'll take a look this weekend.