How does the Express LTS strategy apply to modules not shipped directly with express?

[wesleytodd]

A question came up in expressjs/Admin#3 for how the LTS plan should impact modules under the org. I think we need to have clarity on this, so lets discuss that specifically here.

1. There are packages owned by the project but used widely
2. There are packages who's status quo is not following the same support as express
3. There are packages which benefit greatly from being able to move ahead of the express package itself
4. I don't think we should make any rules which unduly block progress (this last one is opinion while the previous is more objective observations)

cc @blakeembrey @ljharb

[ljharb]

The only rule that makes sense to me is that an express org project must support whatever express core supports. Anything beyond that would be up to that package's maintainers.

[wesleytodd]

Yeah this hinges a bit on the word "support". For example I think it would be alright for a package to work ahead in a major which could drop support for a node version as long as they still "support" (as in bug and security fixes) the existing version. I think ideally we would also commit to accepting feature PRs on those older majors but that could be optional.

Additionally, for things like express-session I think it is perfectly reasonable (as long as the above was met) to publish a new major before express does which starts using new language features or whatever.

Does this meet your expectations here?

[ljharb]

oh sure, that's fair - basically what's important to me:

1. express core is never screwed over, or forced into any change whatsoever, by express org packages
2. express org packages are never forced to drop support for anything simply because express core has dropped it

that indeed doesn't preclude a new major, as long as the previous major that core uses is still fully supported (including backports)

[wesleytodd]

I think this is the kind of language we need verbatim in the policy doc.

[blakeembrey]

Is 1 basically covered by following semver? One thing that you might be hinting at which isn’t covered here is maintenance on versions outside this documents window of maintenance but still used by an active version of express (e.g. I still maintain a 1.x branch of path-to-regexp even though it feels like it’s been a decade since I released newer versions).

To clarify: Express isn’t “screwed over” in any way by this set up, it just hasn’t updated. A lot of interesting stuff occurred after the 1.x release and is used by non-express projects, I wouldn’t want to have been blocked from doing that work.

[ljharb]

1 is covered by semver as long as the old version still gets bugfixes and security fixes - ideally new features, too - exactly as you’ve indicated.

That said, it’s almost never the case in my experience that a breaking change is necessary to do interesting innovation - it can virtually always be done in a semver minor way.

[blakeembrey]

it’s almost never the case in my experience that a breaking change is necessary to do interesting innovation

Sure, but everything is a trade-off. I would like to ensure we're not over indexing on avoiding major versions. If I wanted to keep backward compatibility in path-to-regexp through minor versions, I'd basically have to triplicate the package. Bumping the major version was the reasonable alternative as a maintainer, and I can just maintain 0.1.x separately.

I think it’d be reasonable to stipulate the version used in Express needs to be maintained, requiring features is probably a stretch though. And the maintenance aspect here would definitely fall outside the one year timeframe, so we’d have some packages potentially supporting a minimum of 3 major versions.

[ljharb]

Oh certainly requiring features isn't practical, but it's still nice to strive for it :-)

[wesleytodd]

I think we are generally on the same page, maybe a nice way would be to set requirements and nice to have as separate sections in the doc. Once we nail down that language we can close this issue I think?

[wesleytodd]

We discussed on the working session today and came to this consensus:

It is up to repo captains to make the best decision for that package as long as we keep a supported major line for each supported express major line with current support.

This means that each package can work ahead, make distributed decision making, and do what is best without central decision making around it.