Skip to content
This repository has been archived by the owner on Jul 24, 2024. It is now read-only.

Time to ship 3.0.0? #710

Closed
xzyfer opened this issue Feb 26, 2015 · 28 comments
Closed

Time to ship 3.0.0? #710

xzyfer opened this issue Feb 26, 2015 · 28 comments
Labels
Discussion - Proposal Release - TODO
Milestone
v3.0.0

Comments

@xzyfer
Copy link
Contributor

xzyfer commented Feb 26, 2015

We have a couple of breaking changes on master already, a couple more in the works.

I think we should ship vNext with the update sass binary paths (#695). This opinion in motivated largely due to the volume of io 1.3 issues and knowing that 1.4 is just around the corner.
@am11
Copy link
Contributor

am11 commented Feb 26, 2015

knowing that 1.4 is just around the corner.

Haha! That is so true.

I agree vNext should be 3.0.0 instead. I think we should wait for @matryo to finish #644.

Then I suggest we have alpha release, followed by beta and then RTW. This to nail out proxy related issue: #705 as well as the other planned for the vNext milestone.

@xzyfer did you have any luck with FreeBSD binary? I haven't tried it yet..

@xzyfer
Copy link
Contributor Author

xzyfer commented Feb 26, 2015

@xzyfer did you have any luck with FreeBSD binary? I haven't tried it yet..

honestly I haven't looked into it but I can try to make some time

I think we should wait for @matryo to finish #644.

Sounds good. I mostly wanted to emphasise there's not benefit in waiting for Libsass 3.2 before shipping these great updates. Libsass 3.2 is going to be a while off yet, partially because most of my time is taken up by CSSConf AU at the moment.

@xzyfer
Copy link
Contributor Author

xzyfer commented Feb 26, 2015

I'd also love to have #704 as part of vNext. This will help to ween people off this feature, and prevent the need for a 4.0 with Libsass@3.2 drops.

@xzyfer
Copy link
Contributor Author

xzyfer commented Feb 26, 2015

knowing that 1.4 is just around the corner

https://github.com/iojs/io.js/blob/v1.x/CHANGELOG.md#2015-02-26-version-141-rvagg

@am11 can you confirm that io js 1.4.1 is using the same version on v8 as 1.2?

@am11
Copy link
Contributor

am11 commented Feb 26, 2015

Yes! see the "four minutes ago" story appveyor/ci#147 (comment). 😃

@xzyfer
Copy link
Contributor Author

xzyfer commented Feb 26, 2015

Haha

@am11
Copy link
Contributor

am11 commented Feb 27, 2015

@am11 can you confirm that io js 1.4.1 is using the same version on v8 as 1.2?

Nah it is changed! :(

C:\Users\Adeel\Source\Repos\node-sass>nvmw use iojs-v1.0.0
Now using iojs v1.0.0

C:\Users\Adeel\Source\Repos\node-sass>node -p process.versions.v8
3.31.74.1

C:\Users\Adeel\Source\Repos\node-sass>nvmw use iojs-v1.1.0
Now using iojs v1.1.0

C:\Users\Adeel\Source\Repos\node-sass>node -p process.versions.v8
4.1.0.14

C:\Users\Adeel\Source\Repos\node-sass>nvmw use iojs-v1.2.0
Now using iojs v1.2.0

C:\Users\Adeel\Source\Repos\node-sass>node -p process.versions.v8
4.1.0.14

C:\Users\Adeel\Source\Repos\node-sass>nvmw use iojs-v1.3.0
Now using iojs v1.3.0

C:\Users\Adeel\Source\Repos\node-sass>node -p process.versions.v8
4.1.0.14

C:\Users\Adeel\Source\Repos\node-sass>nvmw use iojs-v1.4.1
Now using iojs v1.4.1

C:\Users\Adeel\Source\Repos\node-sass>node -p process.versions.v8
4.1.0.21

So what should be our course of action now, only support the latest io.js version?
The idea was to release for latest version of io.js and node.js; and (latest - 1) stable-version of node.js.

PS: v8 does not seem to use semantic versioning..

@nschonni nschonni mentioned this issue Feb 27, 2015
Closed
@mgreter
Copy link
Contributor

mgreter commented Feb 27, 2015

@am11 are you sure you cannot just discharge the last digit from v8 verson (you still have 4.1.0, which IMO is exactly semantic versioning).

@am11
Copy link
Contributor

am11 commented Feb 27, 2015

@mgreter, you are right! I thought v8 folks just do not use sem versioning at all. 😸

The binary that was built with iojs v1.1.0 is working with 1.2.0, 1.3.0 and 1.4.0. Which means we need to strip off the last slug from the version (I guess that is a build number in their modified versioning scheme?)

However, the same binary does not work with the first (stable) io.js 1.0.0: Error: Module version mismatch. Expected 42, got 43..

am11 added a commit to am11/node-sass that referenced this issue Feb 27, 2015
@am11
Build: Misc. improvements
851f1b8 
* Remove tests from publishing. sass#683
  * Uses new strategy to validate binary after
    the download.
  * Moves mocha under dev-dependencies in
    package.json.
* Truncates the forth potion from v8 version
  as discussed in sass#710.
* Moves pangyp from dev to main dependencies in
  package.json.
@am11 am11 mentioned this issue Feb 27, 2015
Merged
am11 added a commit to am11/node-sass that referenced this issue Feb 27, 2015
@am11
Build: Misc. improvements.
b1bc102 
* Remove tests from publishing. sass#683
  * Uses new strategy to validate binary after
    the download.
  * Moves mocha under dev-dependencies in
    package.json.
* Truncates the forth potion from v8 version
  as discussed in sass#710.
* Moves pangyp from dev to main dependencies in
  package.json.

Issue URLs: sass#683 and sass#710.
PR URL: sass#717.
am11 added a commit to am11/node-sass that referenced this issue Feb 27, 2015
@am11
Build: Misc. improvements.
fb8786d 
* Removes tests from publishing. sass#683
  * Uses new strategy to validate binary after
    the download.
  * Moves mocha under dev-dependencies in
    package.json.
* Truncates the forth portion from v8 version
  as discussed in sass#710.
* Moves pangyp from dev to main dependencies in
  package.json.

Issue URLs: sass#683 and sass#710.
PR URL: sass#717.
am11 added a commit to am11/node-sass that referenced this issue Feb 28, 2015
@am11
Build: Misc. improvements.
aa70dbb 
* Removes tests from publishing. sass#683
  * Uses new strategy to validate binary after
    the download.
  * Moves mocha under dev-dependencies in
    package.json.
* Truncates the forth portion from v8 version
  as discussed in sass#710.
* Moves pangyp from dev to main dependencies in
  package.json.

Issue URLs: sass#683 and sass#710.
PR URL: sass#717.
am11 added a commit to am11/node-sass that referenced this issue Feb 28, 2015
@am11
Build: Misc. improvements.
9bd034c 
* Removes tests from publishing. sass#683
  * Uses new strategy to validate binary after
    the download.
  * Moves mocha under dev-dependencies in
    package.json.
* Truncates the forth portion from v8 version
  as discussed in sass#710.
* Moves pangyp from dev to main dependencies in
  package.json.

Issue URLs: sass#683 and sass#710.
PR URL: sass#717.
@chriseppstein
Copy link
Contributor

+1 on waiting for #644 this is important functionality. Maybe we can help @matryo put a bow on it if he's too busy to finish it up soon?

@mansona mansona mentioned this issue Mar 4, 2015
Closed
@am11
Copy link
Contributor

am11 commented Mar 4, 2015

@chriseppstein, that will be an utopian scenario. Since we live in a gray-area, node-sass v3 might be released without custom function support the coming weekend, introducing tons of other breaking changes and support for FreeBSD, Oracle Solaris x upper versions of io.js.

However, I agree with you on helping @matryo. I personally have a lot in my TODO list to revamp build process (in particular #712, at least part of it). Nonetheless, I will be volunteering if @matryo would still be busy after we release v3.

@xzyfer
Copy link
Contributor Author

xzyfer commented Mar 5, 2015

Considering @chriseppstein just launched https://github.com/sass-eyeglass/eyeglass I think it's worth waiting for #712.

@am11 am11 added this to the 3.0 milestone Mar 5, 2015
@am11
Copy link
Contributor

am11 commented Mar 8, 2015

@framerate, replying to your question here.

Short answer: soon.

Not very short answer:

I was planning to release v3 this weekend, but there is a stopper: I need a review and testing for #743, so the installation process don't get messed. My plan is to go for release right after that without further waiting for custom function and resolving the side-effects. Also, we can always include custom functions in v3.1, as it won't be a breaking change on node-sass API front.

Right now we need to focus on catching up with frequent changing versions of node-like runtimes. After v3, hopefully things will get stable from build/install perspective and we can focus more on implementing new libsass features.

@am11 am11 mentioned this issue Mar 8, 2015
Closed
@am11
Copy link
Contributor

am11 commented Mar 11, 2015

@xzyfer, ready for binary releases? Lets do an alpha release v3.0.0-preview corresponds to libsass v3.1.0. 😎

I will publish the npm and then we upload the assets, using the upload script. If we don't use the upload script (in favour of web interface, which you can also do when editing the release), then you would need to rename the binary name binding.node to <version-slug>_binding.node. For instance:

darwin-x64-43_binding.node

for iojs v1.1.0 - 1.5.0.

The bright side is, we can defer the binary upload (for instance, FreeBSD binary can land later).

@xzyfer
Copy link
Contributor Author

xzyfer commented Mar 11, 2015

I'm busy for the next couple hours. I'll try to get the osx releases sorted in the next 6hrs.

@xzyfer
Copy link
Contributor Author

xzyfer commented Mar 11, 2015

@am11 I've run into some issue with the upload script. These may be known issues/features. Please clarify.

  • binding is built into ./build/Release not ./vendor
  • node script/upload.js --auth mytoken produces the binding not found error (presumable due to the above).

@am11
Copy link
Contributor

am11 commented Mar 11, 2015 

node scripts/build -f
# binary created in vendor
node scripts/upload --auth mytoken
# binary uploaded to v3.0.0-preview

https://github.com/sass/node-sass/releases/tag/v3.0.0-preview 😉
It is still unpublished.

@am11
Copy link
Contributor

am11 commented Mar 11, 2015

Also to keep the record straight, we should send a PR to node-sass-binaries as well. This will encourage others to send PRs in future.

@xzyfer
Copy link
Contributor Author

xzyfer commented Mar 11, 2015

Should the readme be updated then? These are the step I followed.

git clone --recursive https://github.com/sass/node-sass.git
cd node-sass
git submodule update --init --recursive
npm install
npm install -g node-gyp
node-gyp rebuild  # to make debug release, use -d switch

IMHO we should use npm scripts as the interface for these scripts.

@xzyfer
Copy link
Contributor Author

xzyfer commented Mar 11, 2015

Hmm looks like the upload script doesn't work until a tag is associated with the release.
Is the new node-sass-binaries directory structure documented?

@am11
Copy link
Contributor

am11 commented Mar 11, 2015

Perfect I have created the release. Now scripts/upload is working.

No directory structure required for node-sass-binaries IMO. We can just upload files on root and call it simplified. :)

@xzyfer
Copy link
Contributor Author

xzyfer commented Mar 11, 2015

Yeah that's what I started doing.

@xzyfer
Copy link
Contributor Author

xzyfer commented Mar 11, 2015

From a quick glance at the code this looks about right sass/node-sass-binaries#47

@am11
Copy link
Contributor

am11 commented Mar 11, 2015

Wow you already did it. 👍
I have some work to do before I could make the Linux binaries later today.
That darwin-x64-42 is it iojs-v1.0.0? Well it doesn't matter now, we can upload as many as we want.
GitHub release uses Amazon S3 cloud storage. 😎

@xzyfer
Copy link
Contributor Author

xzyfer commented Mar 11, 2015

That darwin-x64-42 is it iojs-v1.0.0

Yeah I figured better safe than sorry.

@xzyfer
Copy link
Contributor Author

xzyfer commented Mar 11, 2015

Added the OSX binaries

screen shot 2015-03-11 at 4 12 00 pm

@am11
Copy link
Contributor

am11 commented Mar 11, 2015

👍 💯 🎉

@am11
Copy link
Contributor

am11 commented Mar 11, 2015

The pre-release v3.0.0-pre is out. See the breaking changes in README.

npm install node-sass@3.0.0-pre

To see the runtime coverage matrix, see node-sass-binaries readme: https://github.com/sass/node-sass-binaries/#node-sass-binaries.

Let us know what you think on https://gitter.im/sass/node-sass.

@am11 am11 closed this as completed Mar 11, 2015
jiongle1 pushed a commit to scantist-ossops-m2/node-sass that referenced this issue Apr 7, 2024
@mgreter
Merge pull request sass#710 from mgreter/feature/default-args-cust-fn
6173d61 
Fix default argument passing for custom c functions
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Discussion - Proposal Release - TODO
Projects
None yet
Milestone
v3.0.0
Development

No branches or pull requests
4 participants
@chriseppstein @mgreter @xzyfer @am11