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-version-600-current-jasnell [2] https://github.com/nodejs/LTS#lts_schedule
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
