Release proposal: v5.0.1

[rvagg]

The Electron 3 thing is the only major thing in here and controversy there is resolved. I'll publish this in 24 hours unless there are any objections.

• [e3861722ed] - doc: document --jobs max (David Sanders) #1770
• [1cfdb28886] - lib: reintroduce support for iojs file naming for releases >= 1 && < 4 (Samuel Attard) #1777

/cc @MarshallOfSound

[rvagg]

published

[Curtis-D]

Did you re base the branch? I'm missing commit "8b7fdd1fc409029dce248bf543cd7060965539a9"

[rvagg]

@Curtis-D I just pushed out those two commits for a 5.0.1, simply to get them out and deal with the Electron 3 thing. I've queued up a 5.0.2 in #1792, that should go out next week. My release process was a bit messed up and I had to rebase master so 8b7fdd1 became 2761afb and it's in the 5.0.2 list as such.

I'm still trying to figure out the best strategy for releases and branching here that optimises for more regular releases while also allowing for maintenance of older release lines. I've been wanting to avoid a special 5.x branch that cherry-picks from master, like on nodejs/node, because it's going to lead to branch-rot here since there's much less activity and maintenance. But doing it all on master is going to lead to regular rebases unless we put a pause on merges in the lead up to a release—which might not be a big deal if "lead up" is only a day's pause while a release proposal gets reviews. Or, we could just be OK with occasional master tip rebasing.