Feature Overview (aka. Goal Summary)

Red Hat Developer Hub (RHDH) currently follows a rapid release cadence that often outpaces the internal governance, security scanning, and deployment cycles of our large-scale enterprise and regulated customers. Currently, the short support window forces customers into a cycle of "continuous upgrade" simply to remain in a supported state, often requiring them to re-scan and re-validate images every few months.

This feature proposes the introduction of a Long Term Support (LTS) release stream. By extending the support lifecycle (e.g., to 12 months), we provide a stable, predictable target for Platform Engineering teams. This allows customers to satisfy internal security audits and production stability requirements without the overhead of frequent, breaking migrations, while still receiving critical security patches and bug fixes.

Goals (aka. expected user outcomes)

• Reduced Operational Overhead: Customers can maintain a single version of RHDH for up to one year, reducing the frequency of complex migrations.

• Predictable Security Compliance: Security teams can perform deep-dive scans and "gold image" certifications on a stable baseline that won't reach End-of-Life (EOL) before the scan is even completed.

• Stability for Plugin Ecosystems: Internal platform teams can develop and maintain custom Backstage plugins against a stable API surface, reducing the risk of breakages caused by upstream version bumps.

• Improved Planning: Clear visibility into the release roadmap (LTS vs. Interim/Feature releases) allows DevOps leads to align RHDH upgrades with their internal maintenance windows.

Requirements (aka. Acceptance Criteria):

• As a Platform Engineer, I want a designated LTS version of RHDH that receives security backports for 12 months, so that I don't have to upgrade my entire production portal every 3 months to stay supported.
• As a Security Lead, I want a stable image digest that persists for a longer duration, so that my team's vulnerability assessments remain valid for the duration of our production cycle.
• As a Support Lead, I want a published Support Policy document detailing the cadence (e.g., Every even-numbered minor release is LTS), so that customers can plan their 2-year roadmaps.

Out of Scope (Optional)

• Backporting New Features: The LTS stream will only receive critical/important security fixes and high-impact bug fixes; new functionality from the upstream Backstage project will not be backported.
• Extended Support for All Versions: Only specific, designated versions will receive the 12-month window; interim "Feature Releases" will maintain the current shorter lifecycle.

Customer Considerations (Optional)

• Regulated Industries: Customers in Finance and Government often have a 4–8 week "soak time" and scanning period. An LTS release is a mandatory requirement for these segments to adopt RHDH at scale.

• Migration Path: We must clearly define the upgrade path from an outgoing LTS version to the next LTS version (e.g., N to N+2).
• There are several industry standards for LTS/supported versions. For example Java/Spring community will have an LTS every 2 years with other releases in between. OpenShift is doing something similar. Or the NodeJS community will have even/odd minor release for production/development.

Documentation Considerations

• Lifecycle Matrix: Update the Red Hat Customer Portal to include a clear table showing General Availability (GA), Full Support, and Maintenance Support dates for LTS vs. Standard releases.

• Support Policy FAQ: Create documentation explaining how the "LTS" version relates to the upstream Backstage community releases (which move much faster).

• Upgrade Guides: Specific documentation for "Skipping" interim versions when moving between LTS releases.