Confusion regarding “Maintenance LTS” status

[mikeal]

I’ve been reading through the history a bit of how “Maintenance” was changed to “Maintenance LTS.” There seems to be good reasoning behind the wording but what I’m finding is that there are some unintended consequences that need to be resolved.

In my view, maintenance means “get off of this.” In fact, it’s my view that it needs to mean that, especially for libraries since they have to move people early in order to push applications to upgrade before the window closes. The end of maintenance means “no more security fixes.” It means “when this is over it’s potentially harmful to run this version.” But that’s not the way people are interpreting it.

Library authors seem to think that they should ensure support in the most recent versions of their libraries until the end of this window. I don’t think that’s the intention, because we need the ecosystem to be migrating away from this version during that maintenance window if we ever hope to have applications and vendors migrated off before the window closes. There’s a limited number of incentives Node.js has to push an ecosystem this large and complex in a more secure direction, and the current wording and lack of clear direction to developers means the few incentives we have aren’t being used very effectively.

It might be worth changing the language here to clarify the desired behavior of library and application developers and potentially re-wording some of these terms.

[AdamMajer]

In my view, maintenance means “get off of this.”

No, it does not. Every user can decide themselves what it means for them and their applications/libraries.

Library authors seem to think that they should ensure support in the most recent versions of their libraries until the end of this window.

IMHO, it's up to the library developers what they support and when they support it. It's perfectly fine for npm to support nodejs6 even if nodejs6 is no longer maintained. It's perfectly fine for others to require nodejs 14.x and later.

I don't think we need another bike shed discussion about what is a better word to use and why. It's all very clear already.

[bnb]

The end of maintenance means “no more security fixes.”

@mikeal this has historically been my understanding, but I've been corrected on in a handful of times that this isn't actually the case anymore. I'll leave it to people who do the work on this, but I'd just like to +1 my support for being explicit and clear in what Maintenance LTS / Maintenance means.

[richardlau]

The end of maintenance means “no more security fixes.”

@mikeal this has historically been my understanding, but I've been corrected on in a handful of times that this isn't actually the case anymore. I'll leave it to people who do the work on this, but I'd just like to +1 my support for being explicit and clear in what Maintenance LTS / Maintenance means.

I can see some discussion could be had about what being in maintenance means, but I believe we've been fairly consistent that end of maintenance means "no more security fixes".

[bnb]

@richardlau I've been explicitly told privately that the line there is fuzzy. If that's not the case, I'm happy to hear that.

[mikeal]

Some background: when we created the LTS process the releases that were on the initial maintenance schedule (v0.10 and v0.12) had their timelines determined primarily by the OpenSSL maintenance timeline.

This was after years of Node.js not having a regular release cadence so the version of OpenSSL shipped in those releases was quite old and we couldn’t guarantee support or security fixes when we were bound to a crypto dep that wouldn’t be shipping them either.

This is probably where the “no security fixes” messaging originated because we were actively trying to scare people off of old OpenSSL, and if I’m being honest there was also a lack of enthusiasm the io.js contributors who now ran the project had for maintaining the old versions of Node.js that literally drove us to fork the project.

We probably don’t have the exact same concerns having regularly updated all Node.js deps since, but it’s still a bad idea to extend the maintenance window or promise fixes given V8’s release cadence. The end of the Node.js maintenance window is a lot of V8 releases and they guarantee almost zero support for old versions. I’m still working around bugs in the V8 coverage system that are fixed in v14 but will probably never be back ported to v12.

[wesleytodd]

we need the ecosystem to be migrating away from this version during that maintenance window if we ever hope to have applications and vendors migrated off before the window closes.

While I agree with the sentiment of this, I think the reality is much more complicated. Many of the teams I have worked on or with have the same sentiment, but in reality the runtime is not updated until an application is being worked on for another reason and the update "just works" or the security issue is actually exploited.

In the current state of the ecosystem, application authors have to deal with an onslaught of audit reports pushing them to update libs (even though most are invalid) and if those library authors are told to also drop support for node versions in maintenance mode, we are only making it more confusing and difficult for application maintainers to keep up.

---

One thing which I have been pushing is for tooling to support more fluid definition of what runtime versions are supported. We have a proposal in the Package Maintenance WG for aliases (including an implementation) and I have been pushing for tooling support of them (with mixed success). I believe that if every build (library or application) used an alias like lts where it picked the most recent of the lts releases for build and testing targets, it would be a lot easier for maintainers to "set it and forget it".

In this world, I think I could fully get behind trying to migrate libraries during the maintenance window, because it would in theory be less people to migrate, less work to get it done, and less support burden.

Lastly, unless we can actually make it less work in a developers day-to-day, I don't think that language changes will be entirely effective to drive things forward. I am not opposed, I just think it will be surface level change and thus less impactful.

[mikeal]

While I agree with the sentiment of this, I think the reality is much more complicated. Many of the teams I have worked on or with have the same sentiment, but in reality the runtime is not updated until an application is being worked on for another reason and the update "just works" or the security issue is actually exploited.

I hear this a lot and I’m sure it’s true, but I don’t think it’s actually relevant to library developers when deciding when to drop support for old Node.js releases.

You have 3 conditions to consider:

1. An application is not regularly updating.
2. An application is regularly updating.
3. A new application is being built.

A library developer is producing new code and releases strictly for the second two conditions. Existing applications being bound to an older version of Node.js doesn’t actually matter in the decision over what to support in new releases of these libraries. Those applications, by definition, are not being updated and are not a target for adoption of new releases of the library until they decide to upgrade.

It would be different if libraries regularly updated old release lines, but we know that this level of support is incredibly rare is the ecosystem. 99.99% of npm modules have a single current release line they are releasing into and that’s it.

[wesleytodd]

There are additional concerns which mean number 1 still matters to library authors:

• audit resolution
• transitive deps

Both of these can mean that an application in state number 1 still might need to adopt a new package version while still keeping the old runtime. So if a CVE comes out or if a transitive breaks compat, you as the author might not release "new" code but still have to worry about runtime compat.

Also, I agree that we shouldn't optimize for the use case of maintaining multiple major version release lines, but also we should make sure not to widely promote an approach which breaks that need. Especially since some very important packages do support multiple release lines.