Changelog Cleanup

Changelog Cleanup

Cleans up the ## Upcoming Release section of CHANGELOG.md in two phases: grammar/logic review, then sorting into named sections.

Changelog structure

Each release is a ## heading (e.g., ## Upcoming Release, ## 2.3.6). Within a release, entries are organized under named sections — plain-text labels followed by a colon, each followed by a blank line and then bullet entries. For ## Upcoming Release, use the section order defined in Phase 2 below. Older releases may use different section names (e.g., Deprecations:, Breaking changes:, Performance:) or the legacy flat list.

Example structure:

## 2.3.6

New features:

- Entry one

Changes:

- Entry two

Bugfixes:

- Entry three
- Entry four

Dependencies:

- Entry five

Internal:

- Entry visible only in Snowflake-internal or non-customer contexts (see below)

Older releases (before 2.3.6) use a legacy flat list of bullets with no named sections. That format is no longer valid for new releases.

Phase 1: Grammar and Logic Review

1. Read CHANGELOG.md and extract all content under ## Upcoming Release (stop at the next ## heading).
2. For each entry, check for:
   • Spelling and grammar mistakes
   • Unclear or ambiguous phrasing
   • Logical issues (e.g., an entry starting with "Fixed" that actually describes a new feature, or contradictory statements)
   • Entries placed under the wrong section (e.g., a bug fix listed under "New features:", or a customer-visible change under Internal:)
3. When an issue is found, use the AskQuestion tool to present the proposed fix to the user. Provide two options: "Accept" and "Reject". Batch related fixes into a single AskQuestion call when possible to reduce round-trips, but keep each fix clearly labeled.
4. Apply only accepted fixes. Do not modify entries the user rejects.

Phase 2: Sort Entries into Sections

After grammar/logic fixes are applied, sort entries into named sections. The five sections below are the defaults, but you may rename, split, or combine them when it makes the release easier for an end-user to scan — for example, Bugfixes and Performance: instead of a single Bugfixes: bucket. When proposing custom section names, use the AskQuestion tool to confirm them with the user.

Default sections, in this order:

Section 1 — New features:

Entries that semantically describe something new (e.g. Added), regardless of the leading verb.

Section 2 — Changes:

Entries that describe enhancing, changing, updating, removing, refactoring, or modifying existing behavior (e.g. Improved, Changed, Updated, Removed, Replaced), regardless of the leading verb. Dependency bumps belong in Dependencies: (see Section 4), not here.

Section 3 — Bugfixes:

Entries that semantically describe fixing incorrect behavior (e.g. Fixed), regardless of the leading verb.

Section 4 — Dependencies:

Customer-visible dependency changes: bumps (e.g. Bumped axios to ...), removals, replacements, or pins of third-party packages that ship to customers. Include CVE-driven bumps here. Omit this section if the release has no dependency changes.

Internal-only dependency or tooling changes (e.g. dev-dependency bumps, CI tooling) belong in Internal: instead.