RFC: Binary Coverage Matrix

Question

RFC: Binary Coverage Matrix

am11 opened this issue 9 years ago · 24 comments

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.

browniefed commented 9 years ago

👍 Yaye

Answer 1 · 2015-02-09T09:54:53.000Z

@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...

Answer 2 · 2015-02-09T10:01:30.000Z

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

Answer 3 · 2015-02-09T18:24:17.000Z

@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.

Answer 4 · 2015-02-09T19:36:04.000Z

@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.

Answer 5 · 2015-02-09T19:39:23.000Z

@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.

Answer 6 · 2015-02-09T19:53:17.000Z

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.

Answer 7 · 2015-02-10T07:09:59.000Z

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.}.

Answer 8 · 2015-02-11T11:45:42.000Z

@xzyfer, I am building the Windows binaries now for node.js (v0.10 and v0.12) and io.js (v1.1).
Would you rebuild the binaries for Mac as well; targeting the same (sub) matrix?

Note the last batch of commits has a minor change in binding code, hence rebuild the binary for node.js v0.10 and v0.12 is required.

Note 2: you can use nvm to switch between node.js or io.js versions (without installing them manually).

Once this step is done, I will apply the (LibSass gcc 4.4.7) patch and build Linux binaries on CenOS 5.11.

Answer 9 · 2015-02-11T12:37:25.000Z

I'll build the binaries either in the next couple hours or tomorrow depending on how this work out.

FYI io.js 1.2 just shipped!

Answer 10 · 2015-02-11T13:30:57.000Z

Haha, it is hard to even catch up with the minor versions (let alone the patches)!
So yeah io.js v1.2 that would be..
and yay for Mac binaries! 👍

Answer 11 · 2015-02-11T13:34:41.000Z

I'm going to give 1.2 time to settle and ship any patches over night. I've also started looking into Solaris for the lols.

Answer 12 · 2015-02-11T13:43:50.000Z

The mac binaries take me 10mins to build so don't let it hold you up in any way.

Answer 13 · 2015-02-11T18:40:04.000Z

By that logic, we would need to give node.js v0.12.0 sometime time as well.. :)

I think the current latest of both runtimes is a must have. We still have few days before the release.

I am currently having issue with nvmw: hakobera/nvmw#40.

Answer 14 · 2015-02-11T22:37:07.000Z

I would agree if node had a frequent release cycle. Generally speaking the first 24hrs after a release is the danger zone for patch releases.

Answer 15 · 2015-02-11T22:56:26.000Z

Add PRs for Darwin iojs 1.2 and node 0.12 binaries. There appear to have been no changes to the binary for 0.10.

Answer 16 · 2015-02-11T23:14:39.000Z

Great! 👍

However, there was this change:

-  NanNew(ctx_w->result)->Set(NanNew("sourceMap"), source_map); 
+  NanNew(ctx_w->result)->Set(NanNew("map"), source_map);

made in binding.cpp file: f6836c6#diff-672b939c4bdf28c42fc7ba5da56105db. Don't know why compiler would make the ditto binary.. 😕

Answer 17 · 2015-02-11T23:17:36.000Z

Yeah I can't explain it. Maybe the two operations are equivalent in nan ¯_(ツ)_/¯

Answer 18 · 2015-02-12T04:28:20.000Z

With v2.0.0, here is the state of coverage matrix: https://github.com/sass/node-sass-binaries/releases/tag/v2.0.0.

@Turbo87, would you like to send a PR for moving the updated matrix to README, the way you proposed?

Answer 19 · 2015-02-12T08:26:50.000Z

@am11 sure, why not.

Answer 20 · 2015-02-12T14:36:54.000Z

Updated the matrix for v2.0.1 in first post.

Answer 21 · 2015-03-08T20:37:31.000Z

iojs 1.4.1 has upgraded v8 to 4.1.0.21 due to undisclosed security bug ( nodejs/node#952 ) - https://code.google.com/p/chromium/issues/detail?id=430201 (embargoed).

Answer 22 · 2015-03-16T03:30:16.000Z

The information in the original post is outdated.

For v3.0.0-alpha.0 (rebooted preview), please refer to node-sass-binaries repo's readme: https://github.com/sass/node-sass-binaries/blob/master/README.md.
(summary: io.js v1.0.0-v1.5.1 are supported for Linux, Mac and Windows and FreeBSD is available for node.js v0.12)

Once we refactor the docs (#730), we will most probably bring the coverage status to node-sass readme.

Thanks for your comments.

Answer 23 · 2015-05-04T21:43:15.000Z

So, we now have io.js 2.0.0, which defines NODE_MODULE_VERSION to 44