src: introduce process.release object

[rvagg]

Replaces #493 and looking for new feedback.

Requirements: provide URLs to node-gyp for downloading headers and other required files for building native addons. Decoupling it from a hardwired http://nodejs.org/dist/ gives us the ability to provide locations for nightlies, next-nightlies, rcs and any other kind of test builds we want to provide with a working node-gyp. This is also the path to stop patching node-gyp for io.js and into the future gives us the option to continue releasing as iojs (or whatever name we happened to want!) if that's what we decide.

This new PR simplifies from the original approach, requiring only --release-urlbase be passed to configure. It's optional but required for release builds (e.g. make binary RELEASE_URLBASE=https://iojs.org/download/nightly/). We would supply a string such as https://iojs.org/download/nightly/. This gets converted to process.release.sourceUrl, process.release.headersUrl and process.release.libUrl if windows.

A few minor whitespace fixes in Makefile too.

$ ./iojs -pe process.release
{ sourceUrl: 'https://iojs.org/download/nightly/v2.3.5-nightly2015071047e2c5c828/iojs-v2.3.5-nightly2015071047e2c5c828.tar.gz',
  headersUrl: 'https://iojs.org/download/nightly/v2.3.5-nightly2015071047e2c5c828/iojs-v2.3.5-nightly2015071047e2c5c828-headers.tar.gz' }

(on Windows you get a libUrl property that would point to something like 'https://iojs.org/download/nightly/v2.3.5-nightly2015071047e2c5c828/win-x64/iojs.lib')

[thefourtheye]

We can write this simply as o['variables']['node_release_urlbase'] = options.release_urlbase or ''. Should we even need the default value? Other options are not doing that.

[rvagg]

you're right @thefourtheye, it shouldn't be there if it's not set, this is a leftover from a previous incarnation that needed it

[rvagg]

actually it is required for node.gyp

[rvagg]

Suggesting that we land this on next and do node-gyp work there.

[thefourtheye]

gives us the option to continue releasing as iojs (or whatever name we happened to want!)

But the windows part in this patch has hard coded iojs.lib ;-) Is that okay, if the name we choose is something other than iojs?

[rvagg]

there's a few things hardcoded as iojs just like we hardcode that name in many places, the point is that it's hardcoded here and not in node-gyp which will download whatever is at libUrl

[Fishrock123]

Suggesting that we land this on next and do node-gyp work there.

I'm not really sure I see why that would be preferred?

[Fishrock123]

SGTM, can't really comment on the c++ part

[stevenvachon]

Parsing this seems more cumbersome than #493

[rvagg]

I'm not really sure I see why that would be preferred?

@Fishrock123 I guess I don't have a good justification, felt right when I said that but can't seem to come up with good reasoning now

@stevenvachon can you elaborate on what you mean by that comment? The main difference between the two is in what needs to be passed to configure (and Makefile and vcbuild.bat for that matter). There were 3 options that needed to go through via config.gypi into the compilation and now I've reduced it to one, making the assumption that it's safe to hard-wire the specific filenames. The actual process.release object is the same in both this and #493 except for the missing process.release.name property. Or is that the bit that you're concerned about?

[thefourtheye]

@rvagg Wouldn't it be better if we had the corresponding doc changes as well?

[rvagg]

@thefourtheye you mean in doc/api? yeah, I'll do them up as well, tests are a bit harder. I'd really like initial feedback from @nodejs/collaborators first to see if there's any significant push-back on this.

[Fishrock123]

And, for posterity, process.release.name is simply no longer useful in the context of io.js / node.js versioning. There will never be a node.js 1.x or 2.x, as these versions belong to the io.js release line.

[stevenvachon]

@rvagg Oh, I'd misunderstood both issues. Ultimately, I only need process.version now that io.js and node.js have merged.

[rvagg]

@jasnell @cjihrig additional potential uses for process.release for LTS releases:

$ ./node -pe process.release
{
  codename: 'Hydrogen',
  supportEnd: {
    LTS: 'Sat Apr 01 2017 00:00:00 GMT+0',
    maintenance: 'Sat Apr 01 2018 00:00:00 GMT+0'
  },
  sourceUrl: '...',
  headersUrl: '...'
}

[rvagg]

I'm going to go ahead and merge this to master and also to next so I can start testing on a 3.0 RC, which is easier to iterate on that a 2.x release atm. Any objections?

[Qard]

👍 I like the supportEnd idea. It'd be cool to have a userland module that could log warnings when rollover periods are reached.

[rvagg]

derp, I'd better do some docs for this before merging

[Fishrock123]

Any objections?

Hmmm, questions:

1. Downloading the headers still seems messy.
   • Why don't we ship with them?
   • Should we provide an expected cache dir?
2. What goes in the codename and other LTS fields when it's not an LTS?

[rvagg]

@Fishrock123 :

• Downloading the headers still seems messy.
  • Why don't we ship with them?

We do ship them, on all but Windows. It's node-gyp's responsibility to pick them up and use them but that's a non-trivial change. We still need to ship the headers for various reasons, mostly about providing a fall-back even when node-gyp is alert to the installed headers.

• Support versions of Node that ship without headers, e.g. Windows, or bad installs, or someone downloading the iojs.exe or node.exe files we distribute from both iojs.org and nodejs.org.
• iojs.lib and node.lib are also required for compiles, although they should be shipped with the installer when we get around to fixing that. But they fall into the same category here and are still needed for the same reasons.
• node-gyp supports a mode where it can compile for a specific version of node, not necessarily the one you're running. tbh I don't know if that's used anywhere but that feature would have to be removed if there was no way to get the headers.
• node-gyp will need to have the functionality to download source/headers even if we get smart for future versions, at least for the next few years while we phase out current and past versions of Node. Last I looked, the headers that ship with the 0.12 tarballs can't be used to compile because of some missing components so they are useless even if node-gyp could detect where the header files are!

Plus, we are already downloading the entire source tarball, in gzip form, which takes ages on slower links (like my home connection!). Switching to a header tarball is such a huge leap forward already.

• Should we provide an expected cache dir?

Good question, they currently go in to path.join('~/.node-gyp', process.version). When folks were worried that Node.js and io.js versions might overlap it was suggested that we prepend the name of the runtime to that ('node' or 'iojs'). I'm not sure there's a strong need there but perhaps if we wanted the latitude to ship an io.js with an overlapping version number in the future we'd want that. We could achieve it by putting release.name back in and letting node-gyp take care of it. I don't think it makes sense either way to spell out exactly what directory it should be because that's a node-gyp (and possible future replacement build tool) decision.

• What goes in the codename and other LTS fields when it's not an LTS?

shrug, empty? I wasn't proposing it for right now, just as a possibility for consideration later so I don't want us to get hung up on this.

[jasnell]

Oh I like the idea of dropping LTS metadata into this. The only question is
whether it's wise to hard code specific dates...
On Jul 13, 2015 6:44 PM, "Rod Vagg" notifications@github.com wrote:

@jasnell https://github.com/jasnell @cjihrig
https://github.com/cjihrig additional potential uses for process.release
for LTS releases:

$ ./node -pe process.release
{
codename: 'Hydrogen',
supportEnd: {
LTS: 'Sat Apr 01 2017 00:00:00 GMT+0',
maintenance: 'Sat Apr 01 2018 00:00:00 GMT+0'
},
sourceUrl: '...',
headersUrl: '...'
}

—
Reply to this email directly or view it on GitHub
#2154 (comment).

[rvagg]

Updated with docs. Also changed the logic so that if NODE_VERSION_IS_RELEASE and --release-urlbase hasn't been provided it will default to https://iojs.org/download/release/. This is so that anyone taking the source tarball to compile a custom version (for example re-packagers for linux distributions) won't have to know & understand how this all works in order to get a build with this metadata.

[rvagg]

PTAL

[rvagg]

Sorry @Fishrock123, I screwed up my local version of this and didn't have a fixed branch to push because it was sitting against v3.0.0-alpha. I've fixed it up now and it's updated here.

[Fishrock123]

Won't it still be { name: 'io.js' } or at minimum {}?

[rvagg]

good pickup, thanks!

[Fishrock123]

Again. can't comment so much on the C++ or vcbuild stuff, but the rest LGTM minus the docs comment.

[Fishrock123]

Landed in 04fd4fa via 3.0.0