-
Notifications
You must be signed in to change notification settings - Fork 72
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
Comments
Everyone seems to be onboard with the change. Should we just upgrade to |
I think yes, but we need to check depedencies for proper support of |
@hzlmn Cool. They all do. I've been running on |
- already used spread - now uses destruct assign - closes (#242)
As of |
Version |
Do all plugins, need to follow this Node4 support ? Should I use transpiling at runtime to ensure the support ? I know I am a lit bit annoying, but I fallen in love about Fly, and want to do my best. |
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. |
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. |
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 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 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~ |
Hello. Time has passed since the last comment. Node.js 4 is now end of life. We can drop it. |
@otariidae For sure! Next version ( We've been using (new) Taskr at work & it's shaping up nicely. It's about time to extract it & ship it 📦 |
With
beta
, I bumped up minimum Node support to4.6
because it was an LTS release. However, now active4.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 to6.9
before April?In addition to LTS coverage, with
6.9
we also get:Reaction response:
6.9
4.6
Please only comment if you've cast a "reaction" vote.
cc/ @jbucaran @hzlmn @devmondo @Akkuma @tjbenton @watilde @frantic1048 @aweary @pine
The text was updated successfully, but these errors were encountered: