Personally I would like to see the node-v4-level updates completed first, like var -> const and use of classes. Adopting node 6 now could force us to support two versions which would not be practical. I could see switching to node 6 once we are closer to April.

Somewhat related but perhaps more difficult: a way to support existing plugins but also allow asynchronous plugins would be cool.

Ok, it sounds good to me

@johnjbarton, if one wanted to work on the node v4 level updates, is there anywhere you would recommend to start?

We're actually pretty close to the finish line. Look for files with var that are not /client (these are files the ship to the browser).

@johnjbarton, am I right in thinking that both /common and /context are also shipped to the client? It looks like both are processed by browserify in the build process.

Looks like @lusarz got them all huh?

@johnjbarton yeah, now I'm waiting for green light to introduce async/await ;)

@jniles Some times ago I've did some research about possibility to replace var into const/let in /common and /context, but varify didn't wanted to work for me.

If we add async/await and thus create a breaking 4.x version, what will be our plan if we have to create another 3.x release (say a security issue or compat with some dep release)? Doesn't have to be a great option but I'd like to know the cost of the extreme case.

What about forcing users to use node >=8 and forget about karma releases with node 6 support at all ? Are there some use cases when it may not be possible (migrating to node >=8) ?

Yes, I assumed we would drop node v6. So our story could be "Sorry, if you want to use node v6 after 3.1.2, you have to fork the source". I just want to make a clear decision, not an accident and no implied support for two versions at the same time.

Yes, I agree with that.

v3.1.4 seems stable, let's call that the last node 6 version and move on to v4 w/node 8 and async.