Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Poll: Minimum Node Support #242

Open
lukeed opened this issue Jan 10, 2017 · 11 comments
Open

Poll: Minimum Node Support #242

lukeed opened this issue Jan 10, 2017 · 11 comments
Labels

Comments

@lukeed
Copy link
Owner

lukeed commented Jan 10, 2017

With beta, I bumped up minimum Node support to 4.6 because it was an LTS release. However, now active 4.6 LTS is ending in April. And since beta development took a bit longer than expected (IRL, sorry), April isn't very far away.

Poll: Should we continue to stick to 4.6 or bump the minimum version to 6.9 before April?

In addition to LTS coverage, with 6.9 we also get:

  • default function parameters
  • rest parameters
  • spread operator
  • destructuring declarations
  • destructuring assignments
  • destructuring parameters

Reaction response:

  • 👍 for 6.9
  • 👎 for 4.6

Please only comment if you've cast a "reaction" vote.


cc/ @jbucaran @hzlmn @devmondo @Akkuma @tjbenton @watilde @frantic1048 @aweary @pine

@lukeed lukeed added the discuss label Jan 10, 2017
@lukeed
Copy link
Owner Author

lukeed commented Jan 25, 2017

Everyone seems to be onboard with the change. Should we just upgrade to 6.9 now? 🤔

@hzlmn
Copy link
Collaborator

hzlmn commented Jan 25, 2017

I think yes, but we need to check depedencies for proper support of 6.9.

@lukeed
Copy link
Owner Author

lukeed commented Jan 25, 2017

@hzlmn Cool. They all do. I've been running on 6.9 & Fly for a while now.

lukeed added a commit that referenced this issue Jan 26, 2017
- already used spread
- now uses destruct assign
- closes (#242)
@lukeed
Copy link
Owner Author

lukeed commented Jan 28, 2017

As of 2.0.10-beta, Fly now requires Node 6.x.

@lukeed
Copy link
Owner Author

lukeed commented Feb 5, 2017

Version 2.0.2 continues support for Node 4. This will be revisited in April once LTS has officially expired.

@Swizz
Copy link

Swizz commented Feb 21, 2017

Do all plugins, need to follow this Node4 support ?
And what about plugins that uses dependencies that not meet this support ?

Should I use transpiling at runtime to ensure the support ?
Or may I use the engines field (and doc warning) to locked the support ?
To the 6 LTS version or the minimal supported one ?

I know I am a lit bit annoying, but I fallen in love about Fly, and want to do my best.

@lukeed
Copy link
Owner Author

lukeed commented Feb 21, 2017

Lol not annoying at all!

It's entirely up to you since you're the plugin author. However, it would be better for the user to assume that everything will work within the ecosystem.

Obviously, you can't control that in some cases (third-parties). But most existing tools out there are still supporting Node 4 because it is officially still supported. That is why we've reverted to 4.x support.

@mtimofiiv
Copy link

mtimofiiv commented Jul 20, 2017

We are in version 8 now of Node.js. The implementation of the ES2017 spec is almost done. Looking at the support table, I think the amount of extra work needed to make things work with taskr (in < 6) the previous specs is not worth it.

I wholeheartedly agree with the 6+ minimum. I mean come on, that's already 2 major versions ago. If you as a developer are using something less than 6, you can hack together something yourself or use an old version, since you seem to not mind using old software anyways.

I'd rather the package and plugin maintainers spend their time making this work amazing with the modern spec than spend it with compatibility improvements for people stuck in the past.

@lukeed
Copy link
Owner Author

lukeed commented Jul 20, 2017

I neither agree nor disagree, but appreciate your input!

There are cases where some (lazy) cloud solutions only offer a Node 4 solution. Regrettably, they can rightfully do so since Node4 is an official LTS until Apr 2018. That doesn't mean we have to like it haha, but Node.js intentionally allowed this.

On a more important note: There actually isn't anything in 6+ that Taskr would like to use but can't because of its Node4 support. I'm not sure if you saw this PR, but here are all the changes between Node 4 and Node 6 support. It's purely topical niceties -- 99% is to do with require() statements, haha 😆

Similarly, while some 6+ items are more compact, most ES5 code still runs much, much faster than ES6. Because performance is the No.1 priority, that matters. We're only now starting to see meaningful performance improvements (in Taskr's field of view) with nightly 8 builds.

I'd rather the package and plugin maintainers spend their time making this work amazing with the modern spec than spend it with compatibility improvements for people stuck in the past.

I'd completely agree with you, if this were true! 🎉 As mentioned above, there's really no difference in code between 4 and 6. Related, there's no pain & suffering in trying to maintain that commitment.

Hope that helps explains things! I'm more than happy to raise it to 6+ once officially deemed appropriate. Until then, it's really not a bother~

@otariidae
Copy link

otariidae commented Aug 26, 2018

Hello. Time has passed since the last comment.

Node.js 4 is now end of life. We can drop it.
Moreover, new versions of Node.js have been released. We can run tests on Node.js 8 and 10 on CI to support them.

@lukeed
Copy link
Owner Author

lukeed commented Aug 27, 2018

@otariidae For sure! Next version (v3.0) will require Node 8.x

We've been using (new) Taskr at work & it's shaping up nicely. It's about time to extract it & ship it 📦

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants