missing binaries for v0.12.0 or bad reference in shasum file

[UlisesGascon]

I you check the SHASUMS256 file for this release you can see that some files included:

• v0.12.0/genccode.exe
• v0.12.0/genccode.pdb
• v0.12.0/genrb.exe
• v0.12.0/genrb.pdb
• v0.12.0/iculslocs.exe
• v0.12.0/iculslocs.pdb
• v0.12.0/icupkg.exe
• v0.12.0/icupkg.pdb
• v0.12.0/x64/genccode.exe
• v0.12.0/x64/genccode.pdb
• v0.12.0/x64/genrb.exe
• v0.12.0/x64/genrb.pdb
• v0.12.0/x64/iculslocs.exe
• v0.12.0/x64/iculslocs.pdb
• v0.12.0/x64/icupkg.exe
• v0.12.0/x64/icupkg.pdb

The files are not included in this server so all the related requests returned a 404 error. Not sure if the problem is that the binaries are missing or that the file includes more files than expected.

[rvagg]

Gee, you're reaching back into history there! 0.12 was released during the "fork" period, where we put out io.js v1,2,3 and enough pressure was put on Joyent to finally ship an 0.12 which everyone had been begging for for a very long time. I don't recall who put it out, it may have even been James by that point. But IIRC ICU was brand new in the v0.12 branch, it's something that we brought in when we unified under the Foundation and made unified v4.0.0. So my guess is that the release process included all these ICU assets when signing but they weren't something that got shipped. The release process we have today was setup post-v4; although there was some reuse of original Makefile stuff to do some of the work. If you want to do more detective work you could look at the v0.12.0 Makefile and tools/ directory and see what the process was to spit them out and "upload" them (tho .. I have memories of there either not being an explicit upload step, and that it was something that had to be manually done, or it was extremely rudimentary compared to what I ended up putting in Makefile in the io.js lineage).

Or, these files somehow got pruned afterward, but I'm not aware of any pruning that would have done this, once they're in the /releases/ directory they're treated as sacred. I'm pretty sure none of these were useful to ship.

[richardlau]

Or, these files somehow got pruned afterward, but I'm not aware of any pruning that would have done this, once they're in the /releases/ directory they're treated as sacred. I'm pretty sure none of these were useful to ship.

I'm not aware of any pruning either.

FWIW on the server we have

/dev/sda        3.9T  1.3T  2.5T  34% /home
/dev/sdb        2.0T  1.8T   27G  99% /mnt/nodejs_org_home_old

where /mnt/nodejs_org_home_old is the old contents before we moved to the 4 TB disk (#2162 (comment) -- looks like we never discarded the old disk 😅) and the files referenced in the issue description are missing there as well so they haven't been removed by any recent (i.e. in the last three years) pruning (and in any case as @rvagg says we don't prune releases).

If you want to do more detective work you could look at the v0.12.0 Makefile and tools/ directory and see what the process was to spit them out and "upload" them (tho .. I have memories of there either not being an explicit upload step, and that it was something that had to be manually done, or it was extremely rudimentary compared to what I ended up putting in Makefile in the io.js lineage).

https://github.com/nodejs/node-v0.x-archive/blob/v0.12.0/vcbuild.bat#L237-L240 would appear to suggest that only the node*.(msi/exe/pdb) files were expected to be uploaded via vcbuild.bat.

[richardlau]

hah. I was looking for something else, but stumbled across an old Node.js release guide in the archived Node.js wiki that explicitly says for Node.js 0.12.x to log into the staging server and rm icu* genrb* genccode*: https://github.com/nodejs/wiki-archive/blob/38592a57918d2ee159352f1836d951430da5be59/node-v0.x-archive/Node.js-release-guide.md?plain=1#L164-L174

My guess would be the 0.12.0 release is the one where these "unneeded .pdb, .lib and .exe files" were first discovered, and the process amended to deal with them in subsequent releases.

[UlisesGascon]

Thanks for the great explanations @rvagg and @richardlau! I will close the issue for now as we don't plan to do any action yet 😉