bnb/notes.js Secret

## notes.js
// notes on these names, as I'm developing for them:
// - having lts, active, lts_active, and current is confusing. the naming is completely inconsistent and not easily understandable to a layperson who isn't intricately familiar with this specific documentation.
// - if lts_active and lts_latest exist, you're missing lts_maintenance as an alias for lts. again, the naming is extremely confusing.
// - given the apparent need for multiple `lts_*` keywords, having a structured approach rather than a flat approach would make more sense. currently, this structure lives between both flat and strucutred.
// - there is no granularity of support - you either get all or subset, but there's no room for "greater than ${version}" which can be useful in situations where a feature isn't supported before ${version}.
// - there is no option for _only_ maintenance LTS versions.
// - this implementation abuses the word "active" which already has a use case, and both expands the scope of what "active" means while also leveraging its existing definition. This further confuses the already confusing terminology this structure was meant to represent.
	// notes on these names, as I'm developing for them:
	// - having lts, active, lts_active, and current is confusing. the naming is completely inconsistent and not easily understandable to a layperson who isn't intricately familiar with this specific documentation.
	// - if lts_active and lts_latest exist, you're missing lts_maintenance as an alias for lts. again, the naming is extremely confusing.
	// - given the apparent need for multiple `lts_*` keywords, having a structured approach rather than a flat approach would make more sense. currently, this structure lives between both flat and strucutred.
	// - there is no granularity of support - you either get all or subset, but there's no room for "greater than ${version}" which can be useful in situations where a feature isn't supported before ${version}.
	// - there is no option for _only_ maintenance LTS versions.
	// - this implementation abuses the word "active" which already has a use case, and both expands the scope of what "active" means while also leveraging its existing definition. This further confuses the already confusing terminology this structure was meant to represent.