Could we name module to http2.0?

[MylesBorins]

It seems like one of the bits of pushback we are getting on removing the flag for http2 in 8.x before LTS is that there is already a module named 'http2' and it would be disruptive to the ecosystem to remove the flag.

I would like to propose calling the module 'http2.0', which currently does not exist on npm. This would future proof our implementation allowing us to bump semver as http2 moves forward. We could also alias 'http2' -> whatever the latest version of http2 there is. This would also give us the ability to properly deprecate older versions of the protocol without leaving people stranded.

if we do this we should be able to remove the flag from 8.0 and simply not include the explicit http2 call in that version.

[AndrewBarba]

As someone following this repo since day 1, just my thoughts:

1. The existing http2 simply does not work. At all. Anyone using it right now already has a broken system
2. The protocol is called h2 so that would be one acceptable rename (although I dislike it)
3. It's not about calling it something semver, http2.0 is simply not an appropriate name

Just to reiterate: the existing http2 libs are quite broken and not maintained. I think it's even worse to have those libraries remain (with seo linking to those) and then people not finding out about the http2 in core. You guys already have permission from that maintainer to use http2. You should have him transfer the repo to Node.js foundation and update the readme to talk about core. Otherwise you are asking for people to search for http2 and that broken one will come up first.

[akc42]

There was extensive discussion about this in #29, including thoughts on a migration plan. The main issue is that that migration plan should probably already have started, but hasn't

[jasnell]

The author of the existing http2 module is more than happy to hand over the name and has already published a deprecated version of the module to npm. As long as we give people appropriate time to make the necessary adjustments to their code then landing this into 8.x should be ok. That may take a bit longer. Renaming the module would end up being more disruptive and ultimately unnecessary in the end.

What I was thinking for 8.x is that we actually flip the command-line argument (or better yet introduce an environment variable since that carries fewer backwards compatibility issues) that would switch off the new http2 implementation if absolutely necessary. e.g.

$ NODE_DISABLE_HTTP2=1 node 

[mcollina]

@jasnell for that to happen, we need to remove the experimental status from http2. For that to happen, I would like to have the express team be comfortable with the API of http2.

Can we lift that experimental status during the LTS cycle?

[jasnell]

It's a semver-minor addition that, other than taking over the http2 module name, does not introduce any other breaking changes so lifting the experimental status certainly is not out of the question. There's nothing in the LTS policy that says we cannot, at least.

[ofrobots]

@mcollina

@jasnell for that to happen, we need to remove the experimental status from http2.

This suggests that the removal of a flag requires the API to become stable. AFAIK, this is not a documented policy; so perhaps this is conflating two different concerns?

The fact that Node 8 isn't going to have and unflagged http2 sets us at Google Cloud back a whole year. This prevents us from building and releasing an experimental gRPC module and getting real world feedback from users, and then using that to improve the h2 implementation in Node.

[jasnell]

The key and only real concern is the existing module and the impact on those users. Switching this in 8.x to turn built in http2 off addresses that problem, I think.

…

On Thu, Sep 28, 2017 at 12:11 Ali Ijaz Sheikh ***@***.***> wrote: @mcollina <https://github.com/mcollina> @jasnell <https://github.com/jasnell> for that to happen, we need to remove the experimental status from http2. This suggested the removal of a flag requires the API to become stable. AFAIK, this is not a documented policy; so perhaps this is conflating two different concerns? The fact that Node 8 isn't going to have and *unflagged* http2 sets us at Google Cloud back *a whole year*. This prevents us from building and releasing an *experimental* gRPC module and getting real world feedback from users, and then using that to improve the h2 implementation in Node. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAa2eSVjnZ8IO86_OIfIgzaFP9_fN4xSks5sm9NGgaJpZM4PmdpF> .

[MylesBorins]

closing for now... prefer scoped modules as approach