Ember.js 2.1, a minor version release of Ember with additive features only, is released today. This release represents the work of over 82 direct contributors, and over 850 commits.
Ember.js 2.2 beta, the branch of Ember that will be released as stable in roughly six weeks, is also being released today.
New Features in Ember.js 2.1
Changes to the Ember's API in 2.1 are backwards compatible. A summary of the new features in today's release follows.
{{get}} Helper
The {{get}} helper allows dynamic property lookup on objects in templates.
For example, these two usages are equivalent:
{{user.name}}
{{get user "name"}}

A property with a value of a string can be passed as the second argument,
making both the object and the property being read dynamic. For example:
{{get user somePropertyName}}

For documentation on get, reference the API documentation.
Big thanks to @jmurphyau for the
implementation of this feature, and for his excellent
ember-get-helper addon that
demonstrated how useful this helper would be. Using his
ember-truth-helpers addon
in 1.13 codebases is highly recommended.
{{each-in}} Helper
The {{each-in}} helper iterates keys and values of an object. It is similar
conceptually to the for (key in object) { syntax of JavaScript. For example,
this code would display a list of all property names and values on the user
object:

{{#each-in user as |key value|}}

{{/each-in}}

When using {{each-in}}, the iterated list of keys will be unbound. If a new
property is set on user with user.newProp = 'newVal';, the new property
will not appear.
For documentation on the {{each-in}} helper, see the API documentation.
Thanks to @tomdale for the
implementation of this feature, and thanks to
@miguelcamba for his followup PRs.
Registry and Container Reform
The Ember.js registry and container are some of the most extensively used
private APIs in the framework. They
provided one of the only ways to lookup arbitrary objects from Ember's
dependency container.
We are committed to stabilizing this part of the framework and
offering public APIs. This first step creates a normalized way to interact
with register and lookup that we expect to last through the 2.x cycle
and beyond.
In 2.1, Ember.Application instances are passed as the first argument to initializer
hooks. initializer hooks are where dependencies between object types
can be configured, and factories can be registered. Several public APIs will
exist on Ember.Application instances, some of them new:

• register - register a factory
• inject - inject a factory into another factory, or all factories of a type
• unregister - remove a factory from registration
• resolveRegistration - fetch a registered factory
• hasRegistration - check for a registered factory
• registerOption, registeredOption, registerOptions, registeredOptions,
  registerOptionsForType, registeredOptionsForType which manage options
  for a factory (is it a singleton, can it be instantiated).

Ember.ApplicationInstance instances are passed as the first argument to
instanceInitializer hooks in 2.1. instanceInitializer hooks are where
factories can be fetched out of the configured and booted application.
One relevant public APIs exists on Ember.ApplicationInstances:

• lookup - fetch an instance of a factory (with dependencies)

You can find updates to the guides regarding initializers in the revamped Application Concerns section. The
API documentation is similarly updated at the ember-application namespace, Ember.Application class, and Ember.ApplicationInstance class.
This feature also introduces two minor deprecations:

• Expecting two arguments for an initializer hook is deprecated
• Calling appInstance.container.lookup on the first argument to an instance
  initializer is deprecated in favor of appInstance.lookup.

Deprecations flag where we expect to change an API in the future. It is not
recommended that you use deprecated functionality, but you can also safely
silence a deprecation message and continue to use that functionality until
its removal date.
A huge thanks to the tireless @dgeb for his work on the
RFC, implementation, and documentation for these changes. They represent a significant
improvement in Ember's dependency injection system.
Deprecate and Warn Handlers
In the run up to Ember 2.0, it became clear that the tooling for management of
deprecations was poor. One of the reasons for this was the lack of a public,
documented API for deciding how a deprecations and warnings should be handled.
2.1 introduces a proper API for our tooling to build upon.
The default behavior of a deprecation or warning is to log to the console. To change
this behavior, register a handler and write custom logic. For example this
handler would throw an exception for any deprecation messages with the word
should in them:
Ember.Debug.registerDeprecationHandler((message, options, next) => {
if (message.indexOf('should') !== -1) {
throw new Error('Deprecation message with should: '+message);
} else {
// defer to whatever handler was registered before this one
next(message, options);
}
});

In this example, all warnings are silenced:
// next is not called, so no warnings get the default behavior
Ember.Debug.registerWarnHandler(() => {});

Handlers are provided with the following data through arguments:

• message is the text logged by default
• options is an object containing at minimum the property id in the format package-name.specific-deprecation
• next is a caller for the previously registered handler. Often, this is the
  default handler.

Deprecation handlers will also be provided:

• options.until is the version of Ember this feature and deprecation will be
  removed in

As of Ember 2.0, deprecate and warn calls must provide an id option,
and deprecate calls must additionally provide an until option.
Addons not providing this data during
2.x will trigger a deprecation warning.
For more information see the Ember.Debug
API documentsion. This API can be used with previous versions of Ember via the
ember-debug-handlers-polyfill,
though id and until data is not provided until Ember 2.0.
Thanks to @rwjblue for
shipping this API and the polyfill addon, and to @mixonic
for the RFC.
For more details on changes landing in 2.1, review the
Ember.js 2.1.0 CHANGELOG.
Ember.js 2.2 beta
No new features are slated for Ember 2.2. During the canary cycle leading to this beta, the core team and community have been primarily focused on performance improvements or feature work still behind a feature flag.
For more details on changes landing in 2.2, review the
Ember.js 2.2.0-beta.1 CHANGELOG.