node v5.0.0-rc.1 compiled from source thinks it is "node v5.0.0" (period)

[saper]

(from sass/node-sass#1224 (comment)):

I have downloaded:

https://github.com/nodejs/node/archive/v5.0.0-rc.1.tar.gz (length 36691549, md5 977aaea4a16a808ee8f0c112e243470c)

and after compiling it on FreeBSD 10.2 with clang I get:

> node -p process.version
v5.0.0
> node -p process.versions
{ http_parser: '2.5.0',
  node: '5.0.0',
  v8: '4.6.85.28',
  uv: '1.7.5',
  zlib: '1.2.8',
  ares: '1.10.1-DEV',
  modules: '47',
  openssl: '1.0.2d' }
> node -p process.release
{ name: 'node',
  sourceUrl: 'https://nodejs.org/download/release/v5.0.0/node-v5.0.0.tar.gz',
  headersUrl: 'https://nodejs.org/download/release/v5.0.0/node-v5.0.0-headers.tar.gz' }

Is it intentional? If so, how do binary packages for other platforms get their rc suffix?

[Fishrock123]

I think this is intentional. RC builds are built as if it were the release. Perhaps we can change that if necessary.

cc @nodejs/release

[mgol]

@Fishrock123 But the official builds have the -rc.1 suffix so why does it differ from when compiled manually? How is it compiled upstream that it differs?

[targos]

You can add anything after the version number with the --tag configure option:

% ./configure --tag abc && make
% node -v
v6.0.0-abc

[saper]

That's nice, but I'd expect when I check out the git tag source I am getting the same code as the binaries? This is going to be nightmare to debug later. (I understand that not many people compile node from source).

I also notice that download URLs embedded in process.release point to the release directory (https://nodejs.org/download/release/) and not to https://nodejs.org/download/rc/. So now we are having:

% ./configure --tag rc.1 --release-urlbase https://nodejs.org/download/rc/

Anything else?

[targos]

@nodejs/release where can we find all the configure options used for release builds ?

[rvagg]

Sorry, they are tucked away in Jenkins where only Jenkins admins can see it and we can't expose them read-only. @nodejs/build is going to put the XML (yay) into a repo soon so they can be seen and edited by those outside that team.

For Windows it looks something like this:

GYP_MSVS_VERSION=2013
PYTHON=c:\python27\python.exe
NODE_COMMON_PORT=12301
DESTCPU=$DESTCPU
ARCH=$ARCH
DISTTYPE=$disttype
DISTTYPEDIR=
DATESTRING=$datestring
COMMIT=$commit
CUSTOMTAG=rc.$rc
SSHCONFIG=\config
RELEASE_URLBASE=$release_urlbase

vcbuild.bat build-release %ARCH% upload

For others it goes like this:

make -j$JOBS binary-upload \
  DESTCPU="$DESTCPU" \
  ARCH="$ARCH" \
  DISTTYPE="$disttype" \
  DATESTRING="$datestring" \
  COMMIT="$commit" \
  CUSTOMTAG="rc.$rc" \
  RELEASE_URLBASE="$release_urlbase" \
  CONFIG_FLAGS="--download-path=${HOME}/node-icu/"

This is common for all release types, nightlies, rcs and full releases so some of those options aren't used in all situations. The $disttype is one of release, nightly, next-nightly, custom (where custom is used for RC builds for reasons of making it possible to support generic tags). $datestring is user entered where the form date -u +'%Y%m%d' is suggested, this is only actually used for nightly builds. $commit is used in the tag for nightly builds but is also used by Jenkins to select what to check out. $rc is an integer, 0 by default and is only used for custom builds where CUSTOMTAG becomes rc.X. $release_urlbase is one of:

• https://nodejs.org/download/release/
• https://nodejs.org/download/nightly/
• https://nodejs.org/download/next-nightly/
• https://nodejs.org/download/rc/

Follow vcbuild.bat and Makefile for the details on what else happens. The full tasks do an upload to staging which is not what you want to be doing but they call other tasks, e.g in Makefile build mainly uses binary to do the interesting stuff.

[Fishrock123]

Closing this since I think it's been answered, @saper let us know if it shouldn't be :)

[saper]

Well, I learned how to apply tags to whatever I am building from source.

But I still believe that the source code delivered under "rc" (or whatever else) label should be versioned correctly - it can lead to quite a big misunderstanding otherwise....