Sounds like a job for rhscl :-) Denise
> On Apr 26, 2016, at 10:01 PM, Stephen Gallagher <sgall...@redhat.com> wrote: > > 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 > > -- > devel mailing list > devel@lists.fedoraproject.org > http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
