Treehouse Deprecation Dashboard

[swankjesse]

This is an evergreen issue of in-flight deprecations.

Background

We’ve got to worry about 2 kinds of compatibility.

• Regular API compatibility. These work like any open source project: we avoid them when we can, and we make major version bumps when we can’t. (And until we hit 1.0, every release is allowed to make API changes.)

• Cross-Version Compatibility. This is where a host application built with one Redwood version X and a guest application built with version Y need to interoperate smoothly.

Policy

I propose we support the following:

Hosts can run guest code built in the past 4 months, and for the next 16 months

This puts this obligation on app owners that are always up-to-date on Redwood:

• If you’re deploying new guest code, you can target apps up to 16 months old. (Probably closer to 12 months in practice because Redwood-upgrade day is not equal to release day.)
• If you’re deploying new host code, you can only run apps built in the last 4 months.

Deprecation Tracking

• 2023-09-19 ZiplineTreehouseUi.start() changed from 3 arguments to 4. PR link
  • Removed in Remove old ZiplineTreehouseUi.start overloads #2477
• 2023-10-31 ZiplineTreehouseUi.start() changed from 4 arguments to 1. PR link
  • Removed in Remove old ZiplineTreehouseUi.start overloads #2477
• 2024-04-04 ChildrenChange.removedIds is no longer being sent to host PR link
  • Removed in Remove subtree removal synthesis for old hosts #2470
• 2024-04-09 LazyList.placeholders throws when children are removed PR link
  • Removed in Remove subtree removal synthesis for old hosts #2470