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]

Suggested change

	| Modifying an existing default behavior, updating an internal dependency, or refactoring a core algorithm.
	| Modifying behavior or performance of existing requests/configuration.

No: Not usually a dependency update. Not usually a refactoring. Both of those are usually "other".

[dsmiley]

Suggested change

	| For completely new features, capabilities, or opt-in functionality.
	| For changes requiring a user to take action to use (opt-in). Could be completely new features or simply new configuration values on existing features. Documented.

Emphasizing opt-in as the first order gating category.

[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.