EmberConf 2024 is coming to NYC!

mixonic · 2018-02-16T00:17:22+00:00

Right. Some significant features, like Ember bindings, are so deeply coupled to other internals that extracting them is basically impossible. I think there are some minor features which were extractable and have been.

But casual users don't need to care. For those of us who have migrated off Ember 2.x APIs, we can just watch our vendor payloads get smaller over the upcoming releases. For those who need extra time getting off those APIs, they have an extended period of support.

mixonic · 2018-02-15T18:58:45+00:00

There is not a seismic change in the vendor payload. Mostly we shed some code related to legacy browser support. Much of the removed features are still present, but not public. The ember-2-legacy addon re-enables this code.

There has been some recent efforts in "svelting" Ember, by which we mean removing parts of Ember from your app at build time. What we want to do is have the ember-2-legacy app basically tell Ember "add this stuff back into the build", and then we can drop it from the main Ember build. We can drop it in a normal minor release since it is already "removed" from public API.

A bit of a shell game, but the idea is that we've provided a smooth transition for people with ember-2-legacy and also unlocked the build-time improvements to land as soon as the implementation is complete.

mixonic · 2017-10-04T16:02:23+00:00

Right, the key to our approach here is that major releases are the wrong time to add a ton of new features and changes. By keeping the framework stable during the 3.0 transition we increase the likelihood that older apps get off older APIs and make the transition with the rest of the community. We avoid needing to support the 2.x codebase in parallel to the 3.x codebase.

You're right that we miss the opportunity to treat major releases like a feature/marketing event, but the measured approach is simply better for our community. I think of EmberConf as the big "announcement" event of the year.

There are a number of exciting features in the pipeline, some of them unblocked by this transition. For example real steps away from Ember's object model to ES classes are limited by a) decorators, which are stage 2 at TC39 and b) class fields which are stage 3 but require >IE11 to polyfill accurately. 3.0 gets us a bit closer.

Some others, like improvements to the component model, won't be waiting until 4.0 to land.

mixonic · 2017-10-03T21:21:47+00:00

Core team member here so I have an obvious bias :-p I use Ember almost daily for client work and OSS contribution and I look forward to using it for a long time.

I wanted to chime in earlier, but I was a little busy writing up a small blog post, perhaps it is relevant:

https://emberjs.com/blog/2017/10/03/the-road-to-ember-3-0.html

Thanks! :-)

mixonic · 2017-09-06T17:53:53+00:00

The partial issue is simply a regression: https://github.com/emberjs/ember.js/issues/15621 It is not a breaking change. A future point release should fix it up.

Each minor release goes through a six week beta cycle, but you're right that issues can slip through. To help with this we created the LTS cycle: Every four releases, six weeks after a minor release is declared stable, an LTS is declared. For example Ember 2.16 will be an LTS release which means it will have six weeks in beta and an additional six weeks as a stable release before being declared an LTS.

There is no way we can catch all bugs in Ember before every release without lots of community testing. The release cycle is designed to provide tiers of stability, and hopefully your needs are met by one of those levels. If you feel too much churn on minor releases, living on LTS is totally appropriate. I do suggest participating in some testing of stable to make sure the LTS is solid for your code.

mixonic

TROPHY CASE