Although most of our collaboration takes place on Github, IRC
#emberjs on freenode.net), 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:
Tom and Stef still need to discuss how to handle module mode + new semantics next week.
Resolution: Tom and Stef will discuss this week. No, for real this time.
Needs follow up from @xtian.
Resolution: Ping @xtian
Tom and Stef still need to review.
Resolution: Tom and Stef will review.
There are still some decisions around lazy loading code and query params.
resolution: Alex and Stef will discuss lazy stuff.
resolution: stefan will work with David monday or tuesday to get this in. A "Go" then.
resolution: "Go", already in beta
Examples from @machty of current behavior:
- Single static title
- Basic example of titleToken + title
- Basic example of titleToken + title (reversed)
- titleToken bound to controller/model properties
- Overriding doc.title format in deeper routes
resolution: Still "No go", tokenization needs some polish related to nested resources
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.
We reviewed the a proposed change to the process for adding features. This isn't a major departure, just an iteration on what we are currently doing:
- Feature is submitted via PR.
- 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.jsonwith a value of
resolution: "Go" and CONTRIBUTOR.md should be update accordingly.
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).