Replace changelog ADR with "Changelog & Release Info Process"

INFO

This document represents an architecture decision record (ADR) and has been mirrored from the ADR section in our Shopware 6 repository. You can find the original version here

Context

Historically, Shopware used a changelog file workflow based on per-change markdown files under /changelog/_unreleased with an automated build step that aggregated them into CHANGELOG.md and UPGRADE.md.
While technically useful, this caused friction: duplication, missing high-level developer-facing context, and the release notes living in a separate repository.
The team now prefers a curated, in-repo workflow for developer-facing release notes.

---

Decision

1. The ADR 2020-08-03-implement-new-changelog.md is superseded and archived under adr/_superseded/.
2. We adopt a curated in-repo model:
   • RELEASE_INFO-6.<currentMajor>.md: developer-facing release notes with per-minor sections.
   • UPGRADE-6.<upcomingMajor>.md: upgrade instructions and breaking changes.

Example: RELEASE_INFO-6.7.md

## 6.7.5 (Upcoming)
### Core
- Added new `CartRoute` parameter `guestLogin` (PR #12326)
- Improved indexing performance for product categories (PR #12657)
### Administration
- Updated TypeScript target to ES2023 (PR #12408)

Example: UPGRADE-6.8.md

## Deprecated SalesChannelContextSwitcher

The `SalesChannelContextSwitcher` service is deprecated and will be removed in 6.8.  
Plugins using it should migrate to `ContextResolverInterface`.

_(Tip: You can use short headings like “What changed” or “How to adjust” if it helps readability, but they’re not mandatory.)_

3. PR authors must add developer-facing entries as part of their PRs:
   • Information that benefits external developers → RELEASE_INFO-6.X.md (in the “Upcoming” section).
   • Breaking changes → UPGRADE-6.Y.md.
4. Entries should follow this minimal structure (category, concise description, PR reference). CI will not enforce a strict format initially, but reviewers are responsible for verifying consistency and readability.
5. The full, exhaustive changelog for each release will be generated automatically and linked from the release notes.
6. The changelog is the raw, machine-produced record of merged PRs and commits and is intended for engineering/support/partners.
7. The changelog automation will group changes by labels (e.g., bug, feature, performance) and include links to PRs and authors to make the raw changelog navigable.
8. Human-curated files RELEASE_INFO-6.<minor>.md and UPGRADE-6.<major>.md are the primary sources for developer-facing and merchant-facing communications; the autogenerated changelog is complementary and always linked for full traceability.
9. The PR template is updated to reference this process and provide checklist guidance.
10. CI will later validate that either RELEASE_INFO or UPGRADE was updated when relevant (or explicitly skipped with justification).

---

Consequences

• The old ADR is preserved in _superseded for historical reference.
• PR reviewers must ensure developer-facing entries are added or explicitly marked unnecessary.
• Marketing and Comms will pull content only from RELEASE_INFO and UPGRADE, not from the raw changelog.
• Internal documentation (Confluence, DevRel guides) links to these files as the single source of truth for developer-facing release information.
• A future CI enhancement will enforce the presence of these updates where required.

---

References

• Superseded ADR: adr/_superseded/2020-08-03-implement-new-changelog.md