build: enable xz compressed tarballs where possible (v0.12 and v0.10) #4894
Conversation
|
this logic is the same as |
|
LGTM FWIW. I'd be okay with making it non-conditional, mandating that |
|
@bnoordhuis as per the notes, it's annoying on OSX, hence the conditional |
|
I saw that but I assume the OS X buildbots will have it installed so when would it be an issue? People don't generally run it manually, do they? |
|
Yeah, mainly just the release build machines and this is one of the criteria for those, I don't think it gets run much in the wild but it can be used to build tarballs if you download source and I suspect there are come companies out there doing that, unlikely that they'd be doing it for OSX, however! |
|
LGTM here too. I don't mind the conditional much. |
|
I'd prefer the conditional to be consistent with the current v4.x. In addition to OS X, AIX also does not have |
|
Great! |
|
LGTM |
|
so in semver-speak |
|
@ljharb I think it should be |
|
@rvagg any possibility of completing >= 1.0.0 with |
|
@ljharb that'd be painful. Is it important? I mean, 0.10, 0.12 starts midway too. |
|
I don't have visibility into how painful it is for you folks - but every version i have to hardcode into nvm is painful in a long-term sense, whereas creating the xz's seems like it would be painful once. |
|
@ljharb last I checked we did that xz/version check where we just hardcode lowest required versions. Shouldn't that be an ok compromise? |
|
Yes, currently we hardcode 1 version. The current suggestion seems to indicate I'd have to hardcode 3. Just trying to minimize how many I have to manage. |
|
OK, this is a little bit complicated and there are multiple concerns here, both for version managers and for node-gyp. I believe the correct ranges are:
i.e.
Clear as mud? |
|
Thank you for documenting it. Any "backfills" you can do that will condense those three rows, or their resulting columns, into a smaller number of combinations than 9, would be appreciated :-) |
PR-URL: #4894 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Johan Bergström <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: #4894 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Johan Bergström <[email protected]> Reviewed-By: James M Snell <[email protected]>
|
Every tarball has an |
PR-URL: #4894 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Johan Bergström <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: #4894 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Johan Bergström <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: #4894 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Johan Bergström <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: #4894 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Johan Bergström <[email protected]> Reviewed-By: James M Snell <[email protected]>
PR-URL: nodejs/node#4894 Reviewed-By: Ben Noordhuis <[email protected]> Reviewed-By: Johan Bergström <[email protected]> Reviewed-By: James M Snell <[email protected]>
Continuing on from nodejs/build#284
/cc @chorrell, @mscdex, @ljharb, @nodejs/build
We didn't actually agree on anything there but I'm in a why not mood right now.
This will mean that we get .xz tarballs from v0.12.10 and v0.10.42 onwards for those lines. Backing up and providing .xz tarballs for the others is impossible unless we exclude them from the signed SHASUMS file, which is far from ideal so I'm a strong -1 on completing v0.12 and v0.10. Tools like nvm will just have to hardwire in versions numbers for determining when to use .xz and when to use .gz. We're going to have to do something similar in node-gyp to use header files for older versions now that we have them fixed (the same versions will finally have a proper header tarball that can be used).