Core Team Meeting Minutes - 2014/02/07

– By Trek Glowacki

Although most of our collaboration takes place on Github, IRC (#emberjs on, and our Discourse site the Ember.js Core Team meets privately every Friday at 2pm EST/11am PST through Google Hangout for a weekly discussion of all things Ember.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!


@ebryn, @krisselden, @machty, @stefanpenner, @tomdale, @trek, @wagenet, @wycats


Features pending 'Go' decision.

The core team reviewed the following pull requests for inclusion in the 1.5.x beta series:

Features currently slated for 1.5.0 beta series

The core team reviewed the following pull requests for already enabled in canary builds for inclusion in the 1.5.x beta series. All still have a "Go" vote.

  • ember-testing-routing-helpers #3711
  • ember-testing-triggerEvent-helper #3792
  • computed-read-only #3879
  • ember-metal-is-blank #4049
  • ember-eager-url-update #4122
  • ember-routing-auto-location #3725
  • ember-routing-bound-action-name #3936

Feature Process

We reviewed the a proposed change to the process for adding features. This isn't a major departure, but an iteration on what we are currently doing:


  • Feature is submitted via PR.
    • Confirm features.json and have entries.
    • That PR is reviewed, and generally confirmed to be a solid idea
    • PR is merged so makes it into a canary build
  • Feature is added to Features Pending 'Go' Decision Issue
  • New Issue is created with a check-list of items to be completed prior to receiving a 'Go' vote.
    • This should include at least the following entries:
      • Security Audit
      • Core Team Sign-off
    • Should be given a special tag (to make it easy to find later)
    • Should be assigned to the original feature contributor
    • This can serve as the proper place to ask for changes/fixes to the feature
    • Once the feature has gotten a 'Go' decision
      • The issue is closed.
      • It is added to features.json with a value of true.

resolution: "Go" and should be update accordingly.

Security Process

Currently we do security releases all the way back to 1.0.x. At some point that will be untenable (not yet though). There was some discussions about Long Term Support release structures: every odd/even becomes LTS, or even 5th release, or we only support previous three revisions (which would be all releases in the last 4.5 months with our current release model).