Better support for io.js rapid release cycle

[xzyfer]

Io.js 1.3 has been released and is now failing to download the binary.

@am11 I think we should update the install script to be less strict on version mathing for io.js. Their releases more frequently than ours, and are unlikely to have broken older binaries.

I think in the long run it's better for us to assume binaries are good until proven broken (at least for io.js) rather than trying to keep releases in sync.

[Globegitter]

Yep I think that sounds good. Keeping support for all 1.x.x versions sounds imo reasonable.

[am11]

That was fast! Its like yesterday they released v1.2.. 😜

See the comment by @kkoopa #627 (comment). As soon as the minor version changes, it signifies a breaking change and requires a binary rebuild.

However, I can confirm that our iojs-v1.2 binary for win-x64 is working with iojs-v1.3.

For the resolution, I agree that instead of changing the binary names, we should change the install script to fallback to first available version. Here is one way to go about it: where we call the download function, retry with one lesser version in case of 404 and repeat it thrice before giving up.

[Globegitter]

@am11 Doesn't a change in a minor version mean that the API has been changed in a backwards-compatible manner? Or is iojs not follwoing http://semver.org/? That was my reasoning behind the comment - that 1.x changes should not break things in most cases.

This more fundamental discussion aside, I think this sounds like a good solution 👍

[am11]

The current stable version of node.js is v0.12.0 and the major version hasn't been changed yet. It could be that all changes ever made in node.js are backward compatible but those do not account for the breaking changes presented by v8 and libuv (on which the C++ add-on binaries are dependent upon).

[Globegitter]

Oh yeah that is a good point @am11, especially when getting into the land of C/C++ :)

[xzyfer]

An alternate suggestion would be to change the version string in the binary path from the compiled version to the lowest supported version i.e.

- darwin-x64-iojs-1.0
- darwin-x64-iojs-1.2
- darwin-x64-iojs-1.7

This essentially translates to

- darwin-x64-iojs-1.0 < 1.2
- darwin-x64-iojs-1.2 < 1.7
- darwin-x64-iojs-1.7+

Then use the github contents API to query the directory listing.

This makes downloading a compatible binary easy, and makes us future proof for minor changes, compatible changes.

[am11]

@xzyfer, I think with that approach, we will be kind of assuring the user that the downloaded binary is compatible. That approach also means extra work: finding lowest compatible version for each io.js binary with all previous versions up to the available tag: in other words O(n^ln(n)) (all this to detect whether it is choking due to the binary mismatch). 😄

I guess it is different than saying "couldn't find the matching binary, lets see if the previous version works". When it stops working due to some breaking change (after say 3 minor iterations), users will complain, and we will release the newer version.

Nonetheless, we may use GitHub APIs at some point when addressing #56 with node-pre-gyp, unless we decide to go with (node-pre-gyp recommended) Amazon cloud storage bucket. :)

[xzyfer]

That approach also means extra work: finding lowest compatible version for each io.js binary with all previous versions up to the available tag

This is rather simple since we have the version number, and list of available versions. We simple loop decremting the minor digit. It's exactly the same approach you mentioned retry with one lesser version in case of 404 and repeat it thrice before giving up except that we don't need to go over the network.

[am11]

except that we don't need to go over the network

Then we will implement GH API and on install, query the available releases and download the closest lowest version for forward compatibility. So that will be two network requests per install. With the other approach, there is one network request in best case scenario (versions matched) and two more in worse-case scenario. The point is implementing GH API in node-sass build process to avoid three/four network requests sounds overkill.

[nschonni]

@am11 you may want to look at the original binary naming approach which just used platform + v8 version.

[am11]

@nschonni, awesome! It seems like process.versions.v8 is the key criterion.

I just tested, the binary that was built with iojs v1.2.0, works with v1.3.0 as well as v1.1.0, as all three have same v8 version. Also, the one that is built with v0.10.31, works with v0.10.36 (but not v0.12 because v8 differs).