Ember Data 0.13

May 28, 2013 – By Tom Dale

Today, we are pleased to announce the release of Ember Data 0.13.

Ember Data 0.13 is the first official release of Ember Data. This should make it easier for people to synchronize Ember.js and Ember Data versions, and make reasoning about the upgrade process much easier.

Ember Data 0.13

In the past few months, Ember Data has stabilized a lot. We still consider it alpha, and recommend it for production use only to those who like to live on the bleeding edge and contribute back to the project. To make life easier for those folks, though, we will be cutting regular releases like we do with Ember.js.

A few of the many folks involved in the changes in this release include Tom Dale, Yehuda Katz, Cyril Fluck, Igor Terzic, Stefan Penner, Paul Chavard, Gordon Hempton, Peter Wagenet. Thank you to you all and everyone else who has contributed code and others.

API Revision Removal

Now that we are doing regular releases, the API revision check has been removed. You no longer need to provide the API revision number when defining your store:

App.Store = DS.Store.extend({
  // Delete this!
  revision: 13
});

Ember Data Future Plans

Our immediate goals for Ember Data are stabilization, bug fixes, and documentation. There are only two major areas of improvement planned before we beging promoting builds to prerelease and RC versions:

Promises

Currently, most Ember Data APIs return objects that also implement a then() method, allowing them to be used interchangeably as either models or promises.

While this flexibility was convenient, it unfortunately caused confusing semantics. Specifically, because a resolved promise stays resolved, operations like reloading became very confusing.

While not in this release, you should expect that future releases of Ember Data will shift to an entirely promise-based API. This both resolves the issues with confusing semantics as well as allows us to implement some exciting features, like more powerful polymorphism.

Thanks to Stefan Penner for leading the charge on this.

Error Handling

We want to make error handling and dealing with client and server conflicts rock solid. A pull request from Paul Chavard is currently open and looks like a solid starting point for error handling. You should see much more development on this in the near future.