You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Jul 24, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Jul 24, 2024. It is now read-only.
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.
@am11 wouldn't it be better to put the matrix into the https://github.com/sass/node-sass-binariesREADME 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.
@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.
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.
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.}.
Activity
xzyfer commentedon Feb 9, 2015
@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 commentedon Feb 9, 2015
@xzyfer Yes. It would probably be something like:
linux-x64-node-0.10.Turbo87 commentedon Feb 9, 2015
@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 commentedon Feb 9, 2015
@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 commentedon Feb 9, 2015
@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 commentedon Feb 9, 2015
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.
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 commentedon Feb 10, 2015
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.}.
Build: Produces identifiable binary name.
Build: Produces identifiable binary name.
Build: Produces identifiable binary name.
Build: Produces identifiable binary name.
Build: Produces identifiable binary name.
Build: Produces identifiable binary name.
Build: Produces identifiable binary name.
17 remaining items
Windows: Adds binary for v2.0.0.
Windows: Adds binary for v2.0.0.
Windows: Adds binary for v2.0.0.
am11 commentedon Feb 12, 2015
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?
browniefed commentedon Feb 12, 2015
👍 Yaye
Turbo87 commentedon Feb 12, 2015
@am11 sure, why not.
README: Add compatibility/coverage matrix
am11 commentedon Feb 12, 2015
Updated the matrix for v2.0.1 in first post.
saper commentedon Mar 8, 2015
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).
am11 commentedon Mar 16, 2015
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.
saper commentedon May 4, 2015
So, we now have io.js 2.0.0, which defines
NODE_MODULE_VERSIONto 44