BP-2221: Release notes redesign

[jeff-matthews]

Purpose

This pull request (PR) proposes a new design for release notes. It uses content from the v8.4.0 release as a sample for a new 2026 release.

Notable updates include:

• Archives release notes by year, including 2025 (doesn't change URLs)
• Removes the unnecessary release notes overview page and redirects to the redesigned summary page
• Limits summary page to products, versions, link to release notes, and condensed summary based on new feature and enhancement names and fixed issue count (easy to compile with an LLM after writing release notes)
• Adds a shortcut to the release notes summary in the global anchors section at the top-left corner of every page
• Introduces a filterable release notes experience using Mintlify's Update component
• Replaces _[BHE only]_ strings with Badge components
• Applies custom CSS to make deep links to docs more visible in dark mode

Staging

https://specterops-bp-2221-release-notes-redesign.mintlify.app/resources/release-notes/2026-01-14

Known issues

Calling out known issues with these changes that need to be addressed

• Marketing might not be able to use the summary for customer emails
  • We can probably workaround this with some automation to get them a format they can use
• Janky badge rendering in fixed issues lists (before or after text?)
• Discrepancy between categories for new features/enhancements and fixed issues
• Not sure what hot fixes look like yet
  • I think we can treat hot fixes like any other release using the proposed format

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch BP-2221-release-notes-redesign

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[jeff-matthews]

@slokie-so

I pushed a couple of commits to incorporate your initial review feedback.

Add release types to list of filters

Unfortunately, this duplicates the update title. We could replace the title with the detailed feature or enhancement name, but that will inevitably lead to text wrapping because they're longer and less consistent in length. That might not look very nice.

Note

Alternatively, we could implement a custom component that gives us more control over which tags/filters display in the left column.

Added anchor links to summary for each feature/enhancement

Not ideal because it adds maintenance overhead to link to each update, but it definitely emphasizes the release notes linkage if readers miss the note at the top of the page and below the release date heading 😅

[jeff-matthews]

To workaround the duplication issue, I moved the release type into the title. That means it's not filterable though. If that's a hard requirement, then I can revert.

The left column structure is now:

• Product (not filterable) - one of:

  • BloodHound
  • BloodHound Enterprise
  • BloodHound Community (don't think we need this, but it's an option if we do)
  • AzureHound (always maps to Data Collection functional area)
  • SharpHound (always maps to Data Collection functional area)

• Functional area (filterable)

  Can vary by release, but should be based on a standardized list of components (Jira?)

  • Administration
  • API
  • Data Collection
  • Posture
  • Zone Management

• Release type (not filterable) - one of:

  • New feature

  • Enhancement

  • Fixed Issue

    NOTE: We can add more types later if we need to (e.g., known issue, deprecated, breaking change, security, etc)

I also removed the description property that included the version based on internal feedback. Instead, I added the version table from the summary to the top of the detailed release notes page.

Note

We should consider reserving the description property for Action required if/when appropriate.

[jeff-matthews]

See #157