Time for a 3.1 release!

[xzyfer]

It's about a month since our previous release and we've already added 98 commits to master since this release. I'm keen to keep the momentum rolling! We have a lot of good stuff on master as one can see by looking at the closed issues since then.

I'm opening this issue mainly because of @mgreter's incredible API updates. I want downstream libraries to be aware of the impending release and API changes to reduce lag time in implementation.

Open Pull Requests

• Improve custom importer to pass parent import context
• Add tap reporter to test targets
• Add tap output reporter to spec runner
• Improve color token operations
• Implement emitting utf8 charset when seen in output
• Sassc: Use new functional libsass C API

Most need only review or further feedback!

Open Tasks

• update C-API wiki for new API
• update documentation for building libsass
• check wiki for obsolete stuff
• update Readme.md for new API
• Gather changes for release notes
• Add appveyor badge to Readme.md

[mgreter]

I would like to get #691 merged before the next release, since it contains some minor API updates. It already works, but it should be implemented a bit cleaner IMO. BTW. the old API is still in place and should not stop working (if no Sass_Values are used). I also have a branch around for sassc to update to the new API. Beside that there's nothing on my side against 3.0.3 👍

[xzyfer]

I think those things are worth waiting for. I've added a checklist to the issue to track progress.

[mgreter]

OK, I guess/hope I can get my open things sorted out till this weekend!

[xzyfer]

No need to rush :)

I think we're at a point where the remaining issues are significant chucks of work so future releases may be further spread out. It'd be good to get out some of the good stuff on master in the mean time is all.

[HamptonMakes]

We should definitely do a pre-release.

On Tue, Dec 9, 2014 at 5:03 AM, Michael Mifsud [email protected]
wrote:

It's about a month since out previous release. I'm keen to keep the momentum rolling! We have a lot of good stuff on master which I've tried to summaries in https://github.com/sass/libsass/issues?q=milestone%3A3.0.3+is%3Aclosed.
I'm opening this issue mainly because of @mgreter's incredible API updates. I want downstream libraries to be aware of the impending release and API changes to reduce lag time in implementation.

/cc @hcatlin @mgreter @am11

Reply to this email directly or view it on GitHub:
#697

[drewwells]

what wiki updates are you looking for? https://github.com/sass/libsass/wiki/API-Documentation and https://github.com/sass/libsass/wiki/Custom-Functions-internal

[xzyfer]

@drewwells I'm not 100% sure. It was a reference to the still changing C API that @mgreter is working on. Just a reminder to reflect any upcoming changes in the docs.

[xzyfer]

How are you feeling about a pre-release @mgreter ?

[am11]

node-sass can use a corresponding subsequent (pre)release before the holidays. :)

[drewwells]

I'm still unable to get inline warnings (on master) with CSS output with either situation valid SASS prior to the warning or valid SASS after the warning. Is anybody else having this problem?

[mgreter]

@xzyfer, @am11 Nothing speaking against it from my side.
IMO there are two other PRs which could be merged before:
#718 - Improve color token operations
#724 - Add tap reporter to test targets

[xzyfer]

@mgreter I'd prefer we didn't #718 until we're able to fix the regression with hex arithmetic.

Also, has sassc been updated with the latest API changes? We're trying to keep to sassc releases in sync with Libsass.

[mgreter]

@xzyfer I've ammended your original post. Hope you don't mind!?
IMO most open issues are only a question if we want to ship it or not!
I'll push my changes for the perl examples when all PRs are merged/decided!

As for the open Tasks (aka Documentation)
First I want to give some props to @drewwells for his contributions to the API wiki pages!
In the spirit of "momentum rolling", I would love to see if we could gather a bit more documentation for the next release. I will have my share with updating the API docs to make sure it matches the latest. If anyone needs some ideas what could be documented 😉

• what does is_delayed mean?
• what does is_hoistable mean?
• how does the lexer/parser work?
• what are the roles of inspect and eval?
• how is unicode handled?
• what is a environment?
• what is a context?

Or what is your opinion on the documentation situation? IMO I really hope people will continue to contribute to the wiki pages and the documentation! It's very much appreciated from my side!

[HamptonMakes]

I think we should definitely do a pre-release! Helps with integration stuff.

One of you all should do it... I don't have much to show myself on this
release. ;(

On Mon, Dec 15, 2014 at 3:19 PM, Marcel Greter [email protected]
wrote:

@xzyfer https://github.com/xzyfer I've ammended your original post.
Hope you don't mind!?
IMO most open issues are only a question if we want to ship it or not!
I'll push my changes for the perl examples when all PRs are merged/decided!

As for the open Tasks (aka Documentation)
First I want to give some props to @drewwells
https://github.com/drewwells for his contributions to the API wiki
pages!
In the spirit of "momentum rolling", I would love to see if we could
gather a bit more documentation for the next release. I will have my share
with updating the API docs to make sure it matches the latest. If anyone
needs some ideas what could be documented [image: 😉]

• what does is_delayed mean?
• what does is_hoistable mean?
• how does the lexer/parser work?
• what are the roles of inspect and eval?
• how is unicode handled?
• what is a environment?
• what is a context?

Or what is your opinion on the documentation situation? IMO I really hope
people will continue to contribute to the wiki pages and the documentation!
It's very much appreciated from my side!

Reply to this email directly or view it on GitHub
#697 (comment).

[xzyfer]

@mgreter thanks for updating the description. I see you've given yourself a lot to do 😉

As for documentation I think for time being our the best value for time investment will come from gearing it towards integrator i.e. node-sass, perl-sass

As for documenting internals i.e. parser, lexer, visitors.. I like the Ruby sass approach of having nice descriptive code comments. I know there's a lot of debate about the reliability of code comments, but moving them out into a separate system like wiki makes them hard/impossible to version control with features.

IMO I don't think it's worth holding up the current features on master for documentation that doesn't that doesn't block existing implementors.

Thoughts?

[xzyfer]

@hcatlin I'm happy to handle releases. Is there anything I need to do besides create the appropriate gh releases? Do we compile binaries?

[HamptonMakes]

I'm a dick: https://github.com/sass/libsass/releases/tag/3.1-alpha

Anyhow, it needs to be 3.1, since we made interface changes.

[HamptonMakes]

All you do is write up the details! Here is Hampton's Helpful Release Notes

• Start with 2-3 sentence really quick overview
• List new features
• List major bugfixes
• Give as much credit out as you can!!!

Also... make sure we do some RC's for this release (I chose alpha for this one, since it's not a representation of the final... it's just for testing adapters, etc).

[xzyfer]

Thanks for the info. I've tried to assign all the PR shipping since 3.0.2 to the 3.0.3 milestone to help with the write up.

[xzyfer]

Today I managed to clear the remaining tricky issues from the the 3.1 milestone. There were a couple significant issues which I moved to 3.2 (#442, #353, #185). The latter two are actually related, and I've started work on these for 3.2.

IMHO now is as good a time as any to feature freeze 3.1 and prep for a beta release.

@mgreter / @am11 can you confirm if all is good on the node-sass front regarding new C API?

[mgreter]

perl-libsass is ready!

I only have two build related PRs open:

• Feature/build dll win mingw #742
• Do not suppress the compile error code when generating sourcemaps sassc#85

The windows build part should be considered experimental!
IMO updating the build instructions in the readmes should be next todo!

There is also a regression open which I just created a PR for:

• Fix for source-map issues #749

[mgreter]

Merged all the PRs above and will now start to update/write documentation how to build libsass/sassc!

[mgreter]

Looks like the PRs are now built against the repo @hcatlin activated on appveyor. So I guess once @hcatlin deletes his repo (on appveyor), the PRs will then go to the correct url. Anyway, the url we got from @nschonni seems to build master anyway (slowely), so no big deal for now!

[am11]

Thanks @nschonni!

@mgreter, I think this markdown would be more verbose:

[![Build status](https://ci.appveyor.com/api/projects/status/github/sass/libsass?svg=true)]
(https://ci.appveyor.com/project/sass/libsass/branch/master)

produces:

[HamptonMakes]

Should we do this as a New Years release?

[am11]

Yay! 💯 👍

[xzyfer]

I'm on board (in theory) but I think it's worth making sure we ship #789 since we know it causes a crash. Ill to knock it out shortly! Nevermind this was a false alarm!

Let's do it!

I've created a draft 3.1.0 release with change the (massive) curated changelog. I'll leave the honours of the catchy title and preamble to @hcatlin because timezones.

[mgreter]

#789 should be fixed by #791! So lets get that version out! I guess it will not be long till 3.2, since we have a lot of interesting PRs pending already for that! Happy new year to everybody! 🎆

[xzyfer]

I've been giving @hugogiraudel some guidence on this sass-compatibility project. He recently dropped this stat on me

LibSass 3.0.2 -> 44% Sass-Compatibility tests passing.
LibSass 3.1.0 -> 64.64% Sass-Compatibility tests passing.

[KittyGiraudel]

I shall add some extra information to this: it only concerns the 55 or so
tests ran by Sass-compatibility, not the whole suite from Sass-spec.

Also, some features from 3.1 are not yet merged thus unavailable for me to
test. I suspect the support to be around 70-75% or so.

Then among missing features, we have:

• & in SassScript;
• selector manipulation functions;
• deep @extend;
• nested interpolations;
• variable scoping.

[xzyfer]

Sorry I should have been clearer. The significance of sass-compatibility is that it specifically targets inconsistencies between implementations. An increase of 20% means that of all the difference between out implementations there are now 20% less. It's by no means an indication of overall feature coverage.

[KittyGiraudel]

Alright. There are two things I cannot test because I am relying on SassMeister backend for this:

• output style (I think, @xzyfer, you told me that LibSass does not support expanded);
• sourcemaps.

Any incompatibility regarding those two topics are invisible to me.

[xzyfer]

@mgreter is it possible to get #794 shipped soon? sass/sassc#88 essentially makes Libsass unusable for me (and anyone else using sassc).

sass/sassc#88 is the final blocker to 3.1 IMO.

[mgreter]

Can you confirm your bug is solved? If so go on an merge it in. It seems that appveyor did not pick up the changes for sassc somehow (well only for one target). I'll try to ammend that commit to try it again!

[xzyfer]

I'll give it a shot in a couple when I'm by a computer.

[xzyfer]

The problem appears to be solved. Once CI passes I'll create the 3.1.0 release!

[xzyfer]

3.1.0 is live! https://github.com/sass/libsass/releases/tag/3.1.0

Great work team!

[am11]

Congrats! 🎉

[KittyGiraudel]

Congratulations, it looks gorgeous! :)

[drewwells]

Is sassc getting a 3.1 release? Will sassc 3.0.2 be broken against 3.1?

[mgreter]

Sassc is always built to run the tests in our CI, so it should always be compatible with latest libsass! There is actually no need to have the same release cycles for sassc, since we don't release binary anyway!

[drewwells]

So homebrew is pointing at 3.0.2 sassc (not head). If I update libsass to
3.1.0, will this break sassc installs via brew?

On Sun Jan 04 2015 at 11:41:43 PM Marcel Greter [email protected]
wrote:

Sassc is always built to run the tests in our CI, so it should always be
compatible with latest libsass! There is actually no need to have the same
release cycles for sassc, since we don't release binary anyway!

—
Reply to this email directly or view it on GitHub
#697 (comment).

[mgreter]

No idea without actually trying it out! Chances are it still works!

[xzyfer]

We should correct this @drewwells . I'll do a sassc 3.1.0 release shortly. I remember @hcatlin wanted us to do simultaneous releases of Libsass and sassc.

[xzyfer]

It is done https://github.com/sass/sassc/releases/tag/3.1.0

[drewwells]

Thanks, that makes the homebrew release a lot easier. I'm updating brew
test to support the new interface and will add sassc as well.

On Sun Jan 04 2015 at 11:55:44 PM Michael Mifsud [email protected]
wrote:

It is done https://github.com/sass/sassc/releases/tag/3.1.0

—
Reply to this email directly or view it on GitHub
#697 (comment).

[jhnns]

Nice 👍