SOLR-18286: Add Changelog Types Reference to developer documentation

[abumarjikar]

https://issues.apache.org/jira/browse/SOLR-18286

Description

This PR introduces a structured "Changelog Types Reference" guide to the developer documentation (dev-docs/changelog.adoc). It explicitly defines the intended use cases for each changelog classification type (added, changed, deprecated, removed, fixed, and security) to ensure consistency across community contributions and release notes.

Solution

dded an explicit AsciiDoc reference table in dev-docs/changelog.adoc categorizing each valid changelog type with its description and concrete examples.

Tests

No programmatic tests were written as this is a pure documentation update. Verified local formatting layout for the AsciiDoc table preview structure.

Checklist

Please review the following and check all that apply:

• I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
• I have created a Jira issue and added the issue ID to my pull request title.
• I have given Solr maintainers access to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation)
• I have developed this patch against the main branch.
• I have run ./gradlew check.
• I have added tests for my changes.
• I have added documentation for the Reference Guide
• I have added a changelog entry for my change

[janhoy]

I don't think we need a changelog entry for a doc change like this - it makes no sense in context of the shipped Solr tgz to mention that a developer doc has changed.

Else, this is a nice clarification, thanks.

Then a comment, not on your doc but in general about the security type. A security type would not be mutually exclusive with the other types. A change regarding a security issue would always also either be added, changed, deprecated, removed or fixed. I know it is a type recommended by https://keepachangelog.com/en/1.1.0/#how but in practice we never or rarely flag something as security until after a release?

[dsmiley]

What was the source of you writing this; did you guess? I suspect so as it doesn't have "other". See

solr/gradle/changelog.gradle

Lines 70 to 79 in 232690c

	# type:
	# `added` for new features/improvements, opt-in by the user typically documented in the ref guide
	# `changed` for improvements; not opt-in
	# `fixed` for improvements that are deemed to have fixed buggy behavior
	# `deprecated` for marking things deprecated
	# `removed` for code removed
	# `dependency_update` for updates to dependencies
	# `other` for anything else, like large/significant refactorings, build changes,
	# test infrastructure, or documentation.
	# Most such changes are too small/minor to bother with a changelog entry.

which I spent time writing. I wrote it there so that every time someone generates a changelog with Gradle, they see this reference each time in the generated file.

[dsmiley]

@janhoy lets drop this. This is an independent cross-cutting concern. Perhaps we might have a separate loose tagging mechanism with values like "security", "dependency", "perf" -- or just not bother.

[abumarjikar]

Changes made as per the review.

[dsmiley]

Just want to point out we'll have double maintenance of the same info duplicated in adoc & yaml template. But we shouldn't change this often, as the dust continues to settle.

[janhoy]

This is fine.

Regarding security type, I se in https://solr.apache.org/docs/10_0_0/changes/Changes.html that that type is only ever used three times in our entire changelog history. So we can do a followup PR to move those three to other section and formally remove it as a valid type across all tooling and workflows.