Drop support of node v0.10 #816
Conversation
|
LGTM. |
|
LGTM |
|
Wait hold on, looks like EoL is 10-31 not 10-01 |
|
@meeber actually they changed this 9 hours ago. It's clear they've got something against the Lucas Syndicate. |
|
Looks like guys from node are trolling me |
|
The Lucas Syndicate must not be taken down. |
|
Can we merge this now? @meeber @lucasfcosta ? |
|
Do you all know if there's been any coordination or discussion with the Mocha side of things? |
|
@jdalton actually we didn't talk to them yet, but it seems like a good idea. We have released a canary version recently, so it might be a good idea to run some compatibility tests. |
|
\cc @boneskull. |
|
@jdalton Thanks. For the sake of discussion: I understand v0.10 is unsupported.
While Mocha and Chai are the most popular combo of packages, neither requires the other to be present. So to what degree should we maintain compatibility? How important is it we're in sync? Along those lines, we may have significant influence on v0.10 holdouts, simply because of the size of our user bases. It would seem "good" to help drive this forward. But, is it userland's responsibility to drive LTS adoption? |
|
Thanks @jdalton & @boneskull
Critical fixes that are needed in Node 0.10 won't be patched in, so if a vulnerability is found in Node 0.10 - it won't be fixed. In addition, new features which we'd like to utilise will never be supported in these older versions. A concrete example: we use Proxies for a certain feature - we can't use those in 0.10 (or 0.12 or 4.0 but that's another discussion). To put it succinctly - this is an opportunity for us to move the platform forward.
If we don't support 0.10, then we lose a potential portion of our user base who are still using 0.10. We also lose the burden of supporting Node 0.10 - which I guess is a gain, not a loss 😆
None I suppose - but for clarity - Chai 3.5.0 & the upcoming Chai 4 don't actually support IE7. We dropped support for IE7 and IE8 a while ago, or actually - we never really properly supported them (I think).
This may be problematic I suppose?
Good question. I suppose Node 0.10 users can always just use Node's
Another good point - however I'd like to change the train of thought here. While we're in a position of leverage, and could use that to influence LTS adoption, and it is arguable as to whether we should do it or not, there is a more salient point: Chai, and I am fairly sure Mocha have small teams with a big codebase. I feel it is less of a "let's leverage our position" and more a case of "we don't really have resources to support these old versions, while still moving forward with desired features" |
|
From the downstream perspective: When an organization decides to keep running an unmaintained version of Node (e.g., v0.10), they've already made the painful determination that the cost of upgrading Node is greater than the cost of either a) maintaining that version of Node themselves by writing patches as future vulnerabilities are discovered, or b) exposing their servers to those unpatched vulnerabilities. They've also determined that having access to the latest language features isn't a big enough benefit to tip the scales in favor of upgrading Node. Given the decision that they've already made, should such an organization then have a reasonable expectation to use the latest versions of upstream libraries such as Mocha and Chai? Or is having to use Chai v3.5 instead of Chai v4.0 just a relatively small part of the large cost they've already decided to pay by running an unmaintained version of Node? From the upstream perspective: It's up to each library maintainer to decide if they want to pitch in and help pay the cost that's incurred by those running an unmaintained version of Node. That cost is paid primarily by library developers in terms of time. It takes time to maintain compatibility with legacy platforms due to having to troubleshoot and program around one-off behaviors, as well as address user-reported issues specific to legacy platforms. The cost is also shared among all users of the library because less time is spent moving the library forward with improvements, as well as because there are more restrictions in terms of using new language features to make the library better. Maintaining compatibility with legacy platforms also increases complexity of the code due to feature detection and branching logic. It also often has a performance impact, although usually at the micro level. I don't think the benefit of supporting unmaintained versions of Node is worth the cost to Chai. And the downstream organizations that made the decision to run an unmaintained version of Node should already have come to terms with the fact that they're probably not going to be able to use the latest and greatest stuff. It should be stressed that a downstream organization running an unmaintained version of Node (or another library wishing to support unmaintained versions of Node) can still use Chai. They just can't use the latest version. All of this is to say that I agree with a comment made by @keithamus in another thread:
From my perspective, tight coordination between Mocha and Chai in terms of platform support only becomes critical if one of the two libraries decides to drop support for a version of Node that's still officially maintained, in which case it has the potential to negatively impact large groups of users that haven't already gone through the difficult decision making process about running unmaintained software. |
|
Thanks for the comments. Please allow me to prattle. Mocha contains no ES6 features and very few ES5 features. It'd be cool to bring the codebase current. But in reality, there's no resources for such an effort. Holding on to v0.10 support may not be "easier" than simply dropping it, but there's no current proposal on the table that would necessitate v4.x for production use. (We've held back ESLint, so we're feeling this more on the development end. But what's needed for development and what's needed for production don't absolutely need to be equal--and ESLint 3 isn't really compelling enough. In a perfect world, if Mocha drops support, maybe it should have something shiny to entice an upgrade!) Dropping IE7, IE8, and PhantomJS 1.x would bring us to ES5. We could drop many handrolled shims, and the codebase would be simplified. But someone still has to do it. I'd like to drop v0.10, but I'm having a hard time justifying doing that now, in other words. About all I could say is "we'd get the latest version of ESLint". The immediate impact on the maintenance burden would be small, because v0.10 is not our biggest problem--IE7/8 is. Notes: Most of the "Chai" issues I see are users misunderstanding which part of a test failure output comes from where. This is understandable, because Chai makes the determination to fail, but it's up to Mocha to do something with that information. @meeber makes an excellent point that if an org uses an unsupported version of Node.js, they shouldn't expect cool new stuff--or even critical fixes-- from userland. I am probably guilty of losing sight of that. |
|
@boneskull thanks for your input! 😄 Well, even if you don't need v The same applies to IE7/8, if they're not supported anymore, dropping them would just be easier and reduce the maintenance burden. Regarding the issues on both trackers, I think there's no way we can solve this, that totally depends on our users. We can warn them, but this will still happen and I think it's not a big deal, because (IMO) our job as Open Source contributors should be to help people in the first place, so whenever I see an issue that is related to Mocha and not Chai I still do my best to answer it. *PS: * If you guys need any help with upgrading Mocha's codebase I'd be more than happy to contribute. I've been reading your code quite frequently but I'm not fully comfortable about submitting PRs yet. Anyway, we're here to help. |
|
@lucasfcosta Thanks for the offer. Sorry for derailing this discussion, but I don't think people realize the kind of pickle OSS projects like Mocha and Chai are in. I don't have a time series graph to back this up, but I've noted the following from libraries.io: In the two (2) months of August and September 2016:
At the end of October, we lost four (4) core contributors due to inactivity. What's to be done? |
|
FWIW I run Lodash, which is like the Mocha of direct dependencies (instead of dev deps). Fastest growing direct dep, 1,000+ new direct deps each month, billions of downloads, and so on. And like Mocha the core is small (mostly me). With each major bump (which happens once a year) I raise the minimum support bar (dropping older enviros).
With v5 we'll drop Node 0.10 and 0.12 support. |
|
@boneskull, don't worry, you are not derailing the discussion, it's always great to talk about Open Source and see different points of view about it. 😄 IMO, attracting new contributors is one of the maintainer's responsibilities. I see many new folks around trying to find a new project to contribute and none of them offers any help for beginners. I was only able to start contributing to Chai because of @keithamus' detailed explanations about what should be done regarding each issue, after a couple of issues I got ready to start sending contributions more often and got confident about making bigger changes on the codebase. Now that I learned a bit about GitHub's etiquette rules and this kind of thing I also feel more comfortable contributing to other projects. Maybe we, as open source maintainers, should start looking forward to help beginners start contributing and therefore have more people to maintain modules. Thank you all for sharing your thoughts, you rock, buddies ❤️ |
|
@jdalton lol @ adobe illustrator support |
|
|
Agree. Reducing the effort necessary to contribute = more contributors. This is a known equation. 😄 Some part of me worries that more contributions will actually compound the problem. We get more PRs than we can review in a timely manner. If they land, who maintains that code? I'm hesitant to say this, but I will: Mocha doesn't need more contributors. Mocha needs more maintainers. Being a maintainer requires some level of dedication and commitment that's greater than a drive-by PR. How do you convert a contributor to a maintainer? |
For me, I just ask. I repo-sit other projects while primary maintainers are away and find folks that are active in issues and PRs and ask them if they'd like to be a maintainer. That way I can step away from repo-sitting and things are still handled. |
|
@boneskull IMO the most important part is getting a contributor in the first place and then you make that contributor comfortable to send more and more pull-requests. This is achieved by mentoring that person and answering doubts about how the code works. |
|
For what it's worth, my thoughts on this are:
|
|
This is a great conversation everyone! Fun to see lots of maintainers having a good conversation about this. I don't have much more to add about the main point, because everyone has covered it so well so far! I will add this though, about the contributor/maintainer dynamic:
@boneskull here at chai, we have a kind of unwritten rule: if we see a contributor pop up a few times; making a couple of nice PRs and maybe helping out in the issue tracker, we invite them to become maintainers. We started this process this year, and we've since added over a half dozen or so new maintainers, across the chai organisation. Generally speaking everyone has taken their role as maintainer seriously, and made some excellent contributions to the projects. We certainly have a few maintainers who are fairly inactive (that's no problem though, they can help out where they can), and we have some very active ones (e.g. @meeber, @lucasfcosta, @vieiralucas and others). I certainly some trepidation inviting a bunch of folk to come and maintain these projects; but I think once you start you soon realise if people are keen enough to join, they're keen enough to do the job well. The question then becomes, I suppose, how do you get good contributors that you can convert into maintainers? (Personally) I try quite hard to avoid doing any actual work on chai's codebases and instead spend most of my time on the issue tracker; not because I'm lazy but because any work I do is taking away work for potential new contributors to do. Often times I'll end up describing exactly what needs doing to make a PR (an example here) - sometimes to the point where it would have been quicker for me to just code it. Sometimes I'll go and promote these issues in out-of-band channels like twitter or @yourfirstpr. Once we get a contributor making a PR, I try to give them plenty of encouragement and good feedback, as well as lots of congratulations if the PR is merged, as well as a victory-lap of congratulations release PR (an example). If a contributors PR doesn't get merged I'll make a point of apologising and imploring the contributor to keep making good contributions (example 1, example 2). I think that taking the time to write responses in each of these scenarios makes quite a difference in the level of discourse, and the enthusiasm of contributors we have (I have experience on maintaining other projects where this isn't the case and the difference is noticeable). So yeah, I guess ultimately that's a long winded way to say, I guess my role in Chai is more like a coach than a contributor - and I think that has helped us get some great new contributors. If you're looking for a recipe to replicate for Mocha, to try and get some more contribs, I would say we have had success here, doing it this way, so try it! |
|
FWIW, Mocha will drop support in v4 (hopefully tomorrow). changelog |
As @keithamus suggested here, Chai should no longer support node v0.10 since Oct 1st