RFC: Binary Coverage Matrix

[am11]

As @kkoopa mentioned at #627 (comment):

A module must be rebuilt whenever NODE_MODULE_VERSION changes. It changed from joyent/node 0.10 -> joyent/node 0.11, from joyent/node 0.11 -> iojs/io.js 1.0, and atom/atom-shell has its own fork going with yet another NODE_MODULE_VERSION.

we need to confine a binary coverage matrix for the most used versions of runtimes (related: #602 (comment)).

Updated:

The current version of node-sass is v2.0.0-beta v2.0.1 and the distributable binary availability of node-sass is given below:

Availability	Runtime	Version NODE_MODULE_VERSION	Platform	Architecture
	atom-shell	0.21	Linux	ia32
	atom-shell	0.21	Linux	x64
	atom-shell	0.21	Mac	x64
	atom-shell	0.21	Windows	ia32
	atom-shell	0.21	Windows	x64
	io.js	1.2	FreeBSD	ia32
	io.js	1.2	FreeBSD	x64
x	io.js	1.2	Linux	ia32
x	io.js	1.2	Linux	x64
x	io.js	1.2	Mac	x64
	io.js	1.2	Solaris	ia32
	io.js	1.2	Solaris	x64
x	io.js	1.2	Windows	ia32
x	io.js	1.2	Windows	x64
	node.js	0.12	FreeBSD	ia32
	node.js	0.12	FreeBSD	x64
x	node.js	0.12	Linux	ia32
x	node.js	0.12	Linux	x64
x	node.js	0.12	Mac	x64
	node.js	0.12	Solaris	ia32
	node.js	0.12	Solaris	x64
x	node.js	0.12	Windows	ia32
x	node.js	0.12	Windows	x64
	node.js	0.10	FreeBSD	ia32
	node.js	0.10	FreeBSD	x64
x	node.js	0.10	Linux	ia32
x	node.js	0.10	Linux	x64
x	node.js	0.10	Mac	x64
	node.js	0.10	Solaris	ia32
	node.js	0.10	Solaris	x64
x	node.js	0.10	Windows	ia32
x	node.js	0.10	Windows	x64

Note 1: atom-shell does not support FreeBSD and Solaris?
Note 2: This matrix will eventually be added to wiki and we will keep the coverage matrix up to date for the current version of node-sass.

[xzyfer]

@am11 will we need to change the install script and node-sass-binaries to handle the different combinations?

i.e. will node 0.10.x binaries work with node 0.12.x and atom 1.x etc...

[am11]

@xzyfer Yes. It would probably be something like: linux-x64-node-0.10.

[Turbo87]

@am11 wouldn't it be better to put the matrix into the https://github.com/sass/node-sass-binaries README instead of the wiki? that way it would it could always reflect the current state of the repo, you get a history for free and linking to it isn't much harder than linking to the wiki.

[am11]

@Turbo87, I think it would make more sense to add it to node-sass-binaries repo's README and a reference in node-sass' README.

In node-sass' README, we do not want to deliver the message as if it is some kind of set in stone limitation. User can manually build binaries on other platforms with various versions of runtimes. This (incomplete) matrix is only showing the binaries which we might be distributing OOTB.

[Turbo87]

@am11 I know that, and I don't think it will be controversial if you put it exactly like that in the README next to the matrix too.

[Martii]

some kind of set in stone limitation.

Matrices are usually just denoting what's currently supported and not always set in stone. Anyone familiar with node packages knows that things change. Our project for example uses exact semver releases.

User can manually build binaries on other platforms with various versions of runtimes.

Our node host provider won't allow this as I previously mentioned over at the node-sass-binaries repo issues... our provider just happens to be joyent maintained as well.

As a potential further solution for displaying the matrices there is always GH io pages. That could be a common place to bring multiple repos together.

[am11]

Super awesome @xzyfer for Mac binaries! 👍

Keep them coming! 😎

I am trying to figure out a sanest way to differentiate between runtimes, which is yet to be discovered (see nodejs/node-gyp#564 (comment)). I will then update our scripts/{et al.}.