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

"app" blueprint: Update TravisCI config #5679

Merged
merged 5 commits into from
Mar 25, 2016
Merged

Conversation

Turbo87
Copy link
Member

@Turbo87 Turbo87 commented Mar 24, 2016

This PR updates the TravisCI config file in the app blueprint:

  • npm@2 not installed explicitly
  • "npm i bower" in before_install block
  • PhantomJS installed via npm
  • Unnecessary quotes removed
  • Node v4.x instead of 0.12.x

@stefanpenner
Copy link
Contributor

👍

@stefanpenner
Copy link
Contributor

@homu r+

@homu
Copy link
Contributor

homu commented Mar 25, 2016

📌 Commit 92ff5fe has been approved by stefanpenner

@homu
Copy link
Contributor

homu commented Mar 25, 2016

⚡ Test exempted - status

@homu homu merged commit 92ff5fe into ember-cli:master Mar 25, 2016
homu added a commit that referenced this pull request Mar 25, 2016
"app" blueprint: Update TravisCI config

This PR updates the TravisCI config file in the `app` blueprint:

- npm@2 not installed explicitly
- "npm i bower" in before_install block
- PhantomJS installed via npm
- Unnecessary quotes removed
- Node v4.x instead of 0.12.x
@Turbo87 Turbo87 deleted the travis branch March 28, 2016 18:49
homu added a commit that referenced this pull request Mar 31, 2016
"addon" blueprint: Update TravisCI config

similar to #5679
@Turbo87 Turbo87 modified the milestone: v2.5.0 Apr 12, 2016
@mike-north
Copy link
Member

mike-north commented Jun 18, 2016

FWIW, It's now easy for addon authors to introduce problems for node 0.12 users. For example, if they use enhanced object literals in ember-cli-build.js, everything will appear to be fine in CI since it is run against node 4. You'll cut a new release that will hose anyone using node 0.12, as they pull in your new version with their tilde-dependency, and their build will break.

I've tripped over my own shoelaces on this multiple times since ember-cli 2.5 was released.

It's worthwhile to help (and encourage) addon authors to maintain compatibility (when possible) for node 0.12 and all other officially supported node versions that the ember ecosystem is supposed to work with. Particularly in corporate orgs, there may be officially blessed versions of node that are allowed in production, and those may not include recent releases (looking at you @stefanpenner ;) )

What to do about this? - We should consider adding some stuff to the addon blueprint index.js to alter .travis.yml so node 0.12 is used for CI.

@nathanhammond
Copy link
Contributor

@mike-north Your concerns are legitimate. Can you open a PR with 0.12 added back and we'll have the discussion there? Note that regardless of the conclusion in that discussion we will be dropping support for 0.10 and 0.12 on their respective end of support dates (October 1 2016 and April 1 2017, respectively).

@nathanhammond
Copy link
Contributor

Update: it appears that the Node LTS schedule has changed. This means that we will drop support for 0.12 on December 31 2016.

As an aside, was there any discussion on this LTS schedule in public?

/cc @ErisDS

@mike-north
Copy link
Member

mike-north commented Jun 18, 2016

@nathanhammond I don't see any problem with apps using node v4, so my thinking is to leave that as-is, and limit the rollback to the addon blueprint only.

To be clear, this has nothing to do with a debate as to when support for 0.10/12 is dropped. It has not been dropped yet, and although we're all rightfully chomping at the bit to move forward, we need to support it (and help encourage the ecosystem to support it) until that day comes.

Some SemVer discussion needs to be had around this change IMO, because things that used to work will potentially break once this transition happens -- potentially it's addons themselves that need to major-version-incremented when starting to use stuff that's not compatible with node 0.x. Maybe this is an ember-learning team thing, in the form of a PSA or something?

@rwjblue
Copy link
Member

rwjblue commented Jun 18, 2016

It is also possible to deal with this at a linting level. There is at least one eslint plugin that attempts to catch things that are not valid on a given node version (I have used this one), this technique would allow us to encourage best practices by specifying supported version while still taking advantage of recent node engines. I personally would prefer to use node 4 or 6 in CI simply due to the massively improved error messages...

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

Successfully merging this pull request may close these issues.

6 participants