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

hapi-lts requiring node 4 and no updates to hapi 9? #2835

Closed
ldesplat opened this issue Oct 7, 2015 · 9 comments
Closed

hapi-lts requiring node 4 and no updates to hapi 9? #2835

ldesplat opened this issue Oct 7, 2015 · 9 comments
Assignees
Milestone

Comments

@ldesplat
Copy link
Contributor

@ldesplat ldesplat commented Oct 7, 2015

Installing hapi-lts returns the following:

npm install hapi-lts@9
npm WARN engine hapi-lts@9.4.0: wanted: {"node":">=4.0.0"} (current: {"node":"0.10.40","npm":"2.14.5"})

Also, why is the normal npm install hapi@9 not updated? I don't see this documented anywhere?

@nlf nlf self-assigned this Oct 7, 2015
@nlf nlf added this to the 9.4.1 milestone Oct 7, 2015
nlf added a commit that referenced this issue Oct 7, 2015
@nlf
Copy link
Member

@nlf nlf commented Oct 7, 2015

fixed the engine problem in 9.4.1.

there will be no more 9.x releases under the hapi package name

@nlf nlf closed this Oct 7, 2015
@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented Oct 8, 2015

Note that you will need npm 3.x in order for peer deps not to block you due to the name change.

@phated
Copy link

@phated phated commented Oct 9, 2015

@hueniverse can you elaborate why you decided to not use npm tags to publish LTS as "hapi" still?

@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented Oct 9, 2015

My last experience with npm tags are awful. I don't know why it was so bad but even when we set the latest tag on the right version, people still ended up with the wrong release. I just don't trust the tag feature. If someone wants to play with it and prove that it works correctly now, we can move these to the hapi@9.x name.

@phated
Copy link

@phated phated commented Oct 9, 2015

Going to cc @othiym23 here because he uses tags for the npm release cycle.

We are stuck on node 0.10 and npm@^2 for the time being and the peer dep problem is killer

@ldesplat
Copy link
Contributor Author

@ldesplat ldesplat commented Oct 9, 2015

My big problem with the naming change is that existing people on Hapi@9 might think they are getting updates but they not told anywhere to move to hapi-lts. I think that's biggest issue. It is so much more intuitive to continue publishing on hapi@9.

I have minor gripes for plugin's tests then we need to support require('hapi-lts') and require('hapi') depending on which version of Hapi we are testing with. It can be worked around but it's annoying nonetheless.

@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented Oct 10, 2015

Regarding plugins, you will soon need to stop supporting 9.x or older except for critical bugs and security issues. Basically, there are not going to be more 9.x releases except for critical issues. No new features are going to be ported down.

If we can work out the npm tags issues and the proper way to do this, I am happy to publish 9.x on hapi from the lts branch.

@phated
Copy link

@phated phated commented Oct 16, 2015

Just wanted to follow up here. The npm release process (including tagging 2.x as LTS) is documented at https://github.com/npm/npm/wiki/Release-Process

Does hapi have a release script or is it just published with npm publish directly?

@hueniverse
Copy link
Contributor

@hueniverse hueniverse commented Oct 17, 2015

I think we'll just publish under hapi the 9.x lts branch since we are not likely to have many releases. With 11.x we are no longer going to backport anything except for patching critical security issues.

nlf added a commit that referenced this issue Nov 4, 2015
@lock lock bot locked as resolved and limited conversation to collaborators Jan 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants