Plans for Node.js 6.x

[Stephen Gallagher]

OK folks, it's Bad Decision Time.

Today, Node.js 6.0 was released. This is a significant ABI-breaking release,
which means there is no guarantee that existing modules will work with it at all.[1]

Better still, Node.js 5.x is only going to be supported until sometime this
summer, because they're aiming for the 6.x branch to become the new LTS in
October[2]. This puts us in quite a bind.

Fedora disallows major ABI changes in a stable release, so if Fedora 24 Final
ships with Node.js 5.x, we will be stuck with maintaining it until Fedora 24 EOL
(which is probably going to mean until approximately June 2017, or almost a full
year after upstream drops support). This means manually backporting any security
issues that come up without the benefit of a new version to rebase to and with
an increasing likelihood of the patches diverging from upstream.

On the flip side, the major ABI break is hitting us post-Beta Freeze for Fedora
24, which is a really terrible time to be switching to a new major version of a
language runtime (particularly since we don't actually know if any of the other
packages on the system will work with it at all).

We don't have any particularly good options here. A downgrade back to 4.x (which
will be supported until at least April 2018, well past F24 EOL) would be very
difficult at this point, since node modules may have updated to newer,
incompatible versions.

Furthermore, this came at a time where I was planning to write to the nodejs
list and let people know that due to my changing work responsibilities, I'm not
going to be able to be the primary maintainer of the main package any longer.
(I'd be able to swing the occasional minor- or point-release update, but
wrangling a major release won't be possible.)

I realize this is inopportune, but it's best if we figure out *immediately* how
we're going to handle this.


Options:
1) Downgrade back to 4.x, downgrading or dropping any modules in the collection
that don't run on that LTS version.
2) Stick with 5.x for the life of Fedora 24, handling security backports
ourselves once it hits EOL this summer.
3) Upgrade to 6.x, fixing or dropping any modules in the collection that don't
run on it yet.

I'll stick around to help with this major effort (since it's partly my fault
we're in this mess; I didn't realize that the release schedule for 5.x was so
poorly aligned with Fedora 24), but after that I'm going to need someone else to
step up and handle the primary maintenance.


I don't like any of the choices, but I'm going to suggest that option 3) may be
our best choice if we can manage it; we will want to be doing the same work for
Fedora 25/Rawhide anyway, so it's not wasted effort. Also, a lot of the node
modules in Fedora are only there because originally we needed them as
dependencies for npm. Since we recently switched to carrying the embedded npm
(and its rat's-nest of dependencies) inside the main nodejs package, we can
probably get away with breakage in a lot of the modules in the collection.

We may only need to focus in the short term on those packages that are required
by other parts of the Fedora Project (like nodejs-less, which is consumed in the
build process for many web apps).


Option 2) is the path of least resistance in the immediate short-term, but once
we run up against the upstream EOL, the maintenance burden could be prohibitive.
In theory, we could petition FESCo for permission to break ABI in the stable
release, but I wouldn't recommend it (and would probably be voting against it
were it to come from anywhere else; I'd abstain in this case due to conflict of
interest). Given that we know about the potential risk in advance, I doubt we'd
see much sympathy either. So we should realistically assume that if we choose
this option, someone is going to need to maintain the security backports (and it
will not be me, sorry).

As for Option 1)? I think someone with more knowledge of the individual modules
in Fedora (Tom Hughes? Jared Smith?) would need to figure out how many modules
would be broken if we downgraded. If it's sufficiently small, I suppose we could
epoch-bump nodejs and its virtual npm Provides: and go that route. I don't love
that we will effectively been playing yo-yo with the version in F24, but it
would be a solution...


Thoughts, other ideas? Please skip the rotten fruit; I'm on a diet.



[1]
https://github.com/nodejs/node/blob/master/CHANGELOG.md#2016-04-26-versio...
[2] https://github.com/nodejs/LTS#lts_schedule