Re: Plans for Node.js 6.x

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sounds like a job for rhscl :-)
Denise


> On Apr 26, 2016, at 10:01 PM, Stephen Gallagher <sgallagh@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
> http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux