Add release schedule metadata to Node.js inventory by colincasey · Pull Request #1330 · heroku/buildpacks-nodejs

colincasey · 2026-03-20T18:33:46Z

Summary

Adds release schedule fetching to the inventory updater xtask
Inventory output uses [[releases]] format from libherokubuildpack's Schedule type
Each release entry includes requirement (e.g., v24), end_of_life (native TOML date), and inline metadata (start, lts, maintenance dates)
Releases sorted descending by version (v26, v25, ..., v0.12, v0.10, v0.8)
from_inventory falls back to old format for migration

Stacked on #1328

Test plan

cargo clippy --all-targets -- --deny warnings passes
cargo test passes
Inventory format verified ([[releases]] with inline metadata tables, descending order)
Xtask successfully regenerates inventory with schedule

runesoerensen · 2026-03-22T16:09:44Z

I took a stab at implementing this with a slightly different approach #1332 -- mostly to explore a solution that might work well with the Inventory logic / provides some basic plumbing that could be shared :)

runesoerensen · 2026-04-06T03:53:41Z

+                    // Special cases: development releases that don't have their
+                    // own schedule entries. v0.10 also covers v0.9.x, and
+                    // v0.12 also covers v0.11.x.
+                    match minor {
+                        10 => version.minor() == 9,
+                        12 => version.minor() == 11,
+                        _ => false,
+                    }


What is the point of this mapping? Why are we matching v0.9 and v0.11 artifacts to other releases?

It doesn't seem like there's any real value in resolving inacurate release data, presumably to show warnings for unstable/development releases that reached end of life over a decade ago (and that, as far as I can tell, no-one are actually using based on Honeycomb data)?

Replace local `src/utils/vrs.rs` module with shared types from the `nodejs-data` crate. Renames `Requirement` to `Range` throughout and re-exports `NodejsArtifact`/`NodejsInventory` from the shared crate. Removes the `DefaultNodeRequirement` wrapper since `Range` now captures the original string in its Display impl.

…odejs-data

…mStr for NodejsReleaseLine Switch libcnb/libherokubuildpack deps from the add-release-schedule-module branch back to published =0.30.3 crates. Implement release schedule types directly in nodejs-data instead of depending on upstream schedule module. Add FromStr impl for NodejsReleaseLine and fix test compilation errors.

…tory Adapt xtask to use BTreeMap-based NodejsReleaseSchedule, remove toml_edit dependency for inline table formatting, fix sha2 version mismatch, and regenerate inventory with the new [schedule.vN] table format.

colincasey self-assigned this Mar 20, 2026

colincasey marked this pull request as ready for review March 20, 2026 18:34

colincasey requested a review from a team as a code owner March 20, 2026 18:34

schneems approved these changes Mar 20, 2026

View reviewed changes

Comment thread crates/xtask-update-nodejs-inventory/src/node_releases.rs Outdated

Comment thread crates/xtask-update-nodejs-inventory/src/node_releases.rs Outdated

Comment thread crates/xtask-update-nodejs-inventory/src/output.rs