Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

release 1.6.4 #3141

Closed
paulmillr opened this issue Aug 28, 2013 · 52 comments
Closed

release 1.6.4 #3141

paulmillr opened this issue Aug 28, 2013 · 52 comments

Comments

@paulmillr
Copy link

source maps update is good

@lydell
Copy link
Collaborator

lydell commented Aug 29, 2013

And finally we would get better stack traces in mocha.

@paulmillr
Copy link
Author

@michaelficarra @jashkenas

@michaelficarra
Copy link
Collaborator

I see, I see. While I have the ability to make releases if there was an emergency, I've never been able to build the documentation and otherwise prepare a clean release. Let's just wait until Jeremy gets the time to make a release. In my projects, I have a make target to do this so the process is entirely automated: https://github.com/michaelficarra/commonjs-everywhere/blob/f9201f47321424bd353376ea4bb23ae145aff8b8/Makefile#L20-L40

@paulmillr
Copy link
Author

it would be great to document the clean release process also

@rwilcox
Copy link

rwilcox commented Sep 4, 2013

👍

@leeola
Copy link

leeola commented Sep 16, 2013

@lydell re: mocha; Our of curiosity, with this release does Mocha work out of the box? Or do you have to hack/change the behavior of Mocha for the maps to work properly?

@lydell
Copy link
Collaborator

lydell commented Sep 17, 2013

Just use the --compilers option as before, and it will work out of the box!

@robi-wan
Copy link

+1
And finally no more '-p' folders on windows (#2027).

@jashkenas
Copy link
Owner

Working on it ... if anyone wants to pitch in -- hop on IRC, and let's get to it.

@jashkenas
Copy link
Owner

Alright folks -- getting close to being ready for a 1.7.0 release. Please take a minute and bang on master if you can, let me know if you have any outstanding problems.

There are also a couple of open tickets I'd prefer to get cleared up before releasing, to wit:

#3139, #3087, #3059, #3008, #2919 ... and most importantly, although if it doesn't make it, them's the breaks: #2779.

If you have any thoughts on solving those, they'd be much appreciated.

@michaelficarra
Copy link
Collaborator

We should improve #3054 (the fix for #2323) before the next release. I don't want to get that one wrong in a release.

@jashkenas
Copy link
Owner

@michaelficarra -- #3054 didn't get merged. I did this instead:

b173a37

... what exactly should be changed?

@michaelficarra
Copy link
Collaborator

You can't "require coffee-script/extensions" as you claim. You'd need a file in the root, like how I have /register.js in CSR to allow users to require coffee-script-redux/register. Also, can we make the names consistent? I would prefer register, since CSR users have been using that for a while, and it's more descriptive IMO.

@chakrit
Copy link

chakrit commented Oct 30, 2013

@jashkenas @michaelficarra Can we make it so that if a script is loaded via the coffee executable, the handler is automatically registered? Since the user intention is already clear that he/she is gonna be running and requir-ing coffee-script modules from that point.

Here's a very simple test code: https://gist.github.com/chakrit/219bf9153d7cd3014af6. Running coffee main.coffee now breaks with coffee from current master. And yeah, require 'coffee-script/extensions' does not work.

I totally understand the rationale behind splitting out the handler registration but IMO If the user is using the coffee executable directly, then the handler should be auto-registered since the intention and expectation is that we're going to be running many coffee-script modules anyway.

Otherwise many standalone scripts (test runners, self-runnable test files with shebangs, automation scripts, entrypoints, whatnots) will be broken as soon as 1.6.4 lands.

And fixing them is not easy, since you have to figure out which file may or may not be run from the command line and modify each file to invoke the handler registration (could be a lot of files for large projects, which use tap, for example)


p.s. or should I move my comment to #2323 instead?

@aseemk
Copy link
Contributor

aseemk commented Nov 10, 2013

Two quick pairs of cents:

  • register is also the name that Streamline.js uses, and indeed via a register.js file at the root.
  • I agree that the coffee binary should register the extensions; Streamline does this as well.

Edit: I want to say I'm really thrilled to see all the great features and fixes that have been coming. Keep up the fantastic work, everyone. Looking forward to this release!

@michaelficarra
Copy link
Collaborator

Agreed with both of you. That is how CSR behaves:

$ echo console.dir Object.keys require.extensions | bin/coffee -e
[ '.js', '.json', '.node', '.coffee', '.litcoffee' ]

@Quazie
Copy link

Quazie commented Dec 3, 2013

Any status on this update? I'd love to give it a shot.

michaelficarra added a commit to michaelficarra/coffee-script that referenced this issue Dec 8, 2013
You can now `require('coffee-script/register')` to manually register,
and the compiler auto-registers when directly running a coffee file.
@michaelficarra
Copy link
Collaborator

@chakrit: @aseemk: Check out #3279.

@chakrit
Copy link

chakrit commented Dec 9, 2013

@michaelficarra Just tried master and seems it is fixed now. 👍

@lydell
Copy link
Collaborator

lydell commented Dec 9, 2013

Does this new registration thing mean that we should run mocha --compilers coffee:coffee-script/register instead of mocha --compilers coffee:coffee-script?

@michaelficarra
Copy link
Collaborator

@lydell: Yes. Also, if you want to require coffee files from your tests, I believe you need to pass -r coffee-script/register. It's been a while since I've played with my default mocha settings, though.

@aseemk
Copy link
Contributor

aseemk commented Dec 9, 2013

@michaelficarra @lydell: you don't need to pass --require (-r) if you've already passed --compilers. No biggie tho.

@paulmillr
Copy link
Author

@jashkenas @michaelficarra

Can you just ship ANYTHING? I'm pretty tired of dealing with coffeescript issues that were fixed in master 4 months ago

@nfour
Copy link

nfour commented Dec 24, 2013

No chaining syntax and gen support till 2014? Santa gave me socks this christmas.

@jashkenas
Copy link
Owner

A Christmas release it shall be (let's hope).

CoffeeScript was originally released as a festive holiday gift: https://news.ycombinator.com/item?id=1014080 ... so it'll make for a nice anniversary.

@michaelficarra
Copy link
Collaborator

I remember rushing to get a few fixes in before the 1.0 Christmas release, also.

@paulvi
Copy link

paulvi commented Dec 24, 2013

Regular releases at known time points are considered good for any project.
And having some traditions is great.

@jashkenas
Copy link
Owner

Today's not looking likely, I'm afraid, folks — unless someone else wants to do the paperwork, and have me push the button. Cousins in town.

@dashed
Copy link

dashed commented Jan 5, 2014

Take your time.

@robi-wan
Copy link

robi-wan commented Jan 9, 2014

+1
Proper return codes when using --nodejs option - important when using in CI-Servers
(c5120c7)

@paulgration
Copy link

Is there an estimated release date for 1.6.4 yet?

@dashed
Copy link

dashed commented Jan 17, 2014

@pmgration 2015.

@paulmillr
Copy link
Author

Let's move our discussion to more corresponding issue.

@xixixao
Copy link
Contributor

xixixao commented Jan 19, 2014

@paulmillr That's a joke, right? :)

@vendethiel
Copy link
Collaborator

More like a "I've had enough". Original post still stands, though: reopening.

@vendethiel vendethiel reopened this Jan 19, 2014
@lydell
Copy link
Collaborator

lydell commented Jan 20, 2014

Perhaps we should open an "Reduce the amount of paper-work needed to publish a release" issue and an "Formulate a release policy, so that bigger changes don’t block simple bug fixes" issue. But obviously it is not as easy as I might make it sound ;)

@michaelficarra
Copy link
Collaborator

@lydell: Yes, we've been trying to do that for a while. Recently, #3198 made a big step in that direction, moving us away from ruby/ultraviolet for building the docs. Now we can finally automate the release process, or at least get it documented so any of the maintainers can confiedently cut a release. In some of my projects, I have completely automated releases.

@xixixao
Copy link
Contributor

xixixao commented Jan 21, 2014

This probably won't help out people waiting on a new release much, but I pushed coffee-script-nightly to npm, along with generators (--> and yield from) and two other PRs (pushing master itself would be less useful). See README. If someone thinks this a particularly bad idea, let me know.

@jashkenas
Copy link
Owner

but I pushed coffee-script-nightly to npm

I think that's a fantastic idea. Although having coffee-script-master on npm would arguably be even more useful.

@michaelficarra
Copy link
Collaborator

I love the idea of coffee-script-nightly, where we can release frequently, without all the documentation overhead, and get an idea of issues before we make a stable release.

@lydell
Copy link
Collaborator

lydell commented Jan 21, 2014

coffee-script-master kind of already exists "on npm": npm install jashkenas/coffee-script

@jashkenas
Copy link
Owner

npm install jashkenas/coffee-script

I didn't know about that feature. Super useful. Thanks.

@nfour
Copy link

nfour commented Jan 21, 2014

npm install jashkenas/coffee-script should be added to the dox, that is cool.

@xixixao
Copy link
Contributor

xixixao commented Jan 23, 2014

@jashkenas @michaelficarra I think coffee-script-nightly is a bad idea (ironic). I hoped this would nudge Jeremy a bit to make the release. I would be more than happy to help out in any way I can, we really need to release at least some of the bug fixes.

@jashkenas
Copy link
Owner

We certainly do. I'm happy to push the button if someone wants to write up the changelog, and edit the docs to match.

@xixixao
Copy link
Contributor

xixixao commented Jan 23, 2014

@jashkenas I'll look into it, but could you give your opinion on operators (#2887), I think that's well settled; and expansion (#3268), should get either closed or accepted.

@jashkenas
Copy link
Owner

Moving to "Release 1.7.0"...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests