Skip to content
This repository has been archived by the owner on Apr 20, 2019. It is now read-only.

Node v6 support status #88

Closed
60 of 63 tasks
gergoerdosi opened this issue May 18, 2016 · 30 comments
Closed
60 of 63 tasks

Node v6 support status #88

gergoerdosi opened this issue May 18, 2016 · 30 comments

Comments

@gergoerdosi
Copy link
Contributor

gergoerdosi commented May 18, 2016

I'm creating this issue to track node v6 support for the hapi modules.

Repositories

Repositories that have "node" or "6" in their .travis.yml:

  • accept
  • ammo
  • b64
  • bassmaster
  • bell
  • boom
  • bossy
  • call
  • catbox
  • catbox-memcached (Status: requires a refactor, Lead Maintainer: @chapel)
  • catbox-memory
  • catbox-mongodb
  • catbox-redis
  • chairo
  • code
  • confidence
  • content
  • crumb
  • cryptiles
  • faketoe (Status: requires a refactor, Lead Maintainer: @nlf)
  • glue
  • good
  • good-broadcast (Status: waiting for release, Lead Maintainer: @lloydbenson)
  • good-console
  • good-file
  • good-http
  • good-squeeze
  • good-udp (Status: waiting for release, Lead Maintainer: @ulrikaugustsson)
  • h2o2 (Status: waiting for release, Lead Maintainer: @osukaa)
  • hapi
  • hapi-auth-basic
  • hapi-auth-cookie (Status: waiting for release, Lead Maintainer: @jaw187)
  • hapi-auth-hawk (Status: requires a refactor, Lead Maintainer: @dannycoates)
  • heavy
  • hoek
  • inert
  • isemail
  • items
  • joi
  • kilt
  • lab
  • lout
  • mimos
  • nes
  • nigel
  • oppsy
  • peekaboo
  • pez
  • poop
  • rejoice
  • reptile
  • scarecrow
  • scooter (Status: waiting for merge, PR: Test on node v6, update dependencies hapijs/scooter#33, Lead Maintainer: @danielb2)
  • shot
  • statehood
  • subtext
  • topo
  • tv (Status: waiting for merge, PR: Migrate ES6 tv#130, Lead Maintainer: @osukaa)
  • vise
  • vision (Status: waiting for release, Lead Maintainer: @jagoda)
  • visionary
  • wreck
  • yar

Travis

I noticed that the version numbers used in .travis.yml are inconsistent. The most common ones are:

node_js:
  - "4"
  - "6" 
node_js:
  - "4"
  - "node" 

But there are repositories with "5" or "stable". Some repositories were not updated for a while, they include version numbers like "0.10", "0.12", or even "iojs".

I think we should agree on a template and repositories should follow that. Actually the question is whether to use "6" or "node" in addition to "4".

Updates

I will try to keep this list updated, but feel free to update the list if you have access to do so. Also, if I made a mistake (a module supports v6 but I didn't mark it), let me know and I will update the list.

@gergoerdosi
Copy link
Contributor Author

In issue #80 @hueniverse said (#80 (comment)) to use "4" and "6", so I went ahead and started to open pull requests.

@hueniverse
Copy link
Contributor

Great!

@AdriVanHoudt
Copy link
Contributor

@gergoerdosi this is awesome! If possible we could link to the PR's created for clarity?

@vdeturckheim
Copy link

@gergoerdosi Great work !
There is a PR on good-upd updating to the latest good version + es6 refactor + travis targets updates

@gergoerdosi
Copy link
Contributor Author

@vdeturckheim: Great! Updated the status:

@AdriVanHoudt: Good suggestion. Added the PRs and also the lead maintainers, so we can immediately see who we needs to do some work.

@nlf
Copy link
Contributor

nlf commented May 19, 2016

is "waiting for release" relevant if the only change required was adding node 6 to the travis config? i don't think updating CI configuration is worth publishing a new version over IMO

@cjihrig
Copy link
Contributor

cjihrig commented May 19, 2016

Agree with @nlf, that's why I hadn't published some of mine after updating.

@hueniverse
Copy link
Contributor

If the published version passes tests, no need for a new one just for CI.

@gergoerdosi
Copy link
Contributor Author

True. Hapi's shrinkwrap is set to patch versions, so it's enough that the latest release works on v6. I will mark those modules done then.

@hueniverse
Copy link
Contributor

However, if you change tests or anything in package.json, I would publish a minor version just to keep things clean.

@gergoerdosi
Copy link
Contributor Author

I went through the list again, but it's not easy to decide whether a module can be considered ready for v6. For some it was clear, if the only commit after the latest release was the v6 test, then I marked it as ready. But there are modules that have a lot of change since the last release, for example b64, good-broadcast, h2o2, or isemail. I kept the requires release note there. The last one, isemail, is special, package.json has been updated with version 2.1.1 and 2.1.2, but the latest release on npm is 2.1.0.

@devinivy
Copy link
Contributor

@gergoerdosi updated lab for me in topo. Does that merit a release per @hueniverse?

However, if you change tests or anything in package.json

@gergoerdosi
Copy link
Contributor Author

The list should be complete now. PRs were submitted to all repositories that didn't have v6 in travis.yml. Where the status says "waiting for release", either a dependency was updated, or there were other code changes since the last release.

@devinivy
Copy link
Contributor

devinivy commented May 19, 2016

You deserve a medal :) thank you!

@hueniverse
Copy link
Contributor

Statehood fails the tests now because of something that changed in v6. I don't have time to dig into it but it looks like the prototype doesn't match between the parsed cookies object and the plain object passed in the tests in some deep equal checks.

@gergoerdosi
Copy link
Contributor Author

Yes, I noticed that too. Already working on it. The prototypes are easy to fix (can be disabled in expect()). However looks like one test case uses deep equal for object comparison, and a message in that object is different on v4 and v6. Need to figure out how to test it the best way. I will try to come up with a PR soon.

@AdriVanHoudt
Copy link
Contributor

Is there a reason nothing is noted behind hapi itself?

Also any maintainers looking for PR's, as long as it is not super complex (since I don't know all the modules) I am happy to help out!

@gergoerdosi
Copy link
Contributor Author

gergoerdosi commented May 20, 2016

Hapi comes last. Eran wrote in #80 (comment):

First is getting lab to work on it. Then each hapi core module needs to test on it.

Of course we don't need to wait for all modules to be updated, the list looks already good. But there are still a few direct dependencies of hapi that are not tested, for example peekaboo or statehood (the latter works, just need to fix the tests). And there are a few popular modules that I think should be tested too before we can say hapi is compatible with v6, for example glue, h2o2, or vision.

Anyway, added a status to hapi too.

@hueniverse
Copy link
Contributor

I am going to wait for code v3 on all hapi dependencies before I move hapi to v6.

@cjihrig
Copy link
Contributor

cjihrig commented May 20, 2016

@hueniverse I can publish code v3 right now. Are you OK with the current state of it for v3?

@hueniverse
Copy link
Contributor

@cjihrig yep. It does all I want.

@cjihrig
Copy link
Contributor

cjihrig commented May 21, 2016

Published. Good luck with your tests everyone :trollface:

@hueniverse
Copy link
Contributor

Sweet!

@geek
Copy link
Contributor

geek commented May 21, 2016

@cjihrig lab is now updated and published with the latest... no issues with moving to code v3.

@hueniverse
Copy link
Contributor

Core is done and published under v13.4.1. Go use your fancy node v6.

@cadecairos
Copy link

I've just pushed out v2.0.0 of bassmaster, supporting node 4 and 6, with full test coverage.

@gergoerdosi
Copy link
Contributor Author

Quick update:

Thanks for all the maintainers for their support!

@lostthetrail
Copy link

@gergoerdosi Scooter PR has been merged and released as 4.0.0.

@x37v
Copy link

x37v commented Nov 15, 2016

been a while since there has been an update here.. any news with the v6 status?

@gergoerdosi
Copy link
Contributor Author

I'm not working for the company anymore where we used hapi, so I'm not following the changes either. If somebody wants to take over the maintenance of the list feel free to do so, maintainers are able to check / uncheck items. Otherwise I suggest to close this issue.

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

No branches or pull requests