restructure announcements for 8.6

[christinaausley]

Description

Restructure 8.6 announcements -- follow up to #5221.

When should this change go live?

• This is a bug fix, security concern, or something that needs urgent release support. (add bug or support label)
• This is already available but undocumented and should be released within a week. (add available & undocumented label)
• This is on a specific schedule and the assignee will coordinate a release with the DevEx team. (create draft PR and/or add hold label)
• This is part of a scheduled alpha or minor. (add alpha or minor label)
• There is no urgency with this change (add low prio label)

PR Checklist

• My changes are for an upcoming minor release and:
  • are in the /docs directory (version 8.8).
  • are in the /versioned_docs/version-8.7/ directory (version 8.7).
• My changes are for an already released minor and are in a /versioned_docs directory.

• I added a DRI, team, or delegate as a reviewer for technical accuracy and grammar/style:
  • Engineering team review
  • Technical writer review via @camunda/tech-writers unless working with an embedded writer.

[christinaausley]

@pepopowitz With the build issue, is this associated with the versionMapping.spec.ts file, docusaurus.config.js, and/or perhaps index.js? I have changed the route to the release notes link in the "current" version -- but not sure if I need to make these changes in these files as well, even if these changes aren't in versions older than 8.5? If this is too complicated, we can also just keep the changes to 8.8 and 8.7.

Some screenshots for a quick look:

[pepopowitz]

@pepopowitz With the build issue, is this associated with the versionMapping.spec.ts file, docusaurus.config.js, and/or perhaps index.js?

2 of the 3 will definitely need to change as part of this PR: docusaurus.config.js, and index.js. The config is rendering the footer items, and those appear on every single page, regardless of version -- that's why you're seeing so many broken links, because every single page has exactly one. Index.js is the home page only, but that link will appear as broken in the build. If it weren't masked by a single broken link on every single page, you would see that link as broken in the build.

versionMapping.spec.ts doesn't need to change for this PR to go green, because we don't actually run those tests as part of the build. I mostly use those when we cut a new version, to spot check, that I didn't mess things up. I can change this the next time we cut a version.

[akeller]

@pepopowitz should these also include the versioned /8.6/ URLs?

[pepopowitz]

If we follow existing practices, no. /8.6/ URLs will currently redirect to / URLs, which will be caught by these rules.

But I think there is a bigger conversation, about whether those existing practices should be changed now that we added the /8.6/ -> / redirect. I'll start a conversation in Slack. I don't believe that conversation should block this PR, because if we change existing practices I'll have to go fill in all sorts of redirects, not just these few.

[christinaausley]

@pepopowitz Merging this, but let me know if we need to go back through the redirects.

[akeller]

I did not review the exact content, but the structure looks as I would expect. I had one question about redirects and if they need to include the 8.6 versioned URLs too, but I wouldn't consider that blocking.