This has been an incredibly good conversation. People have discussed a few different topics and I wanted to try to tackle them.
First, I think people agree, by and large, that Ember itself has maintained remarkably good stability, and that upgrades of Ember have taken relatively little time on a per-release basis.
As a few people have said, we’ve all experienced big-bang upgrades before, and our goal is to make it possible for people to do regular, incremental upgrades without interrupting their flow, and while maintaining compatibility. The goal of the 6-week-cycle isn’t to reduce the overall pace of change, but rather to make the change digestable and easy to explain and message.
Along these lines, one of our goals is to ensure that upcoming changes are messaged as deprecation warnings ahead of time, with these rules:
- Before removing a feature (including in a breaking release like 2.0), it must have been marked as deprecated in the previous series.
- All deprecation warnings much come with information on what to migrate to. We shouldn’t deprecate things without an already in place path to move to.
What this means is that in the run-up to Ember 2.0, which has a somewhat aggressive plan for Svelte’ification, rendering engine improvements, and programming model improvements, you’re seeing a lot of deprecations. We could have, instead, avoided the deprecations and asked you to make the changes once 2.0 hit, but issuing deprecations ahead of time, incrementally, and when a path forward already exists makes it easier to migrate a bit at a time.
Again, we aren’t trying to reduce the overall pace of change, but rather to make it more manageable. Our rule is: it should always be possible to upgrade from one point release of Ember to the next in the context of an existing sprint.
That doesn’t mean that upgrades are always totally painless, or that there’s nothing we could be doing better. The community has been great about both reporting problems and coming together to find solutions, and I’m very proud of how much we’ve been able to innovate as a group on Open Source release management.
All of that said, it seems like a bigger issue than Ember itself is aspects of the Ember ecosystem that are rapidly coming together as we approach Ember 2.0, especially Ember CLI and Ember Data.
One particularly big change is the transition from globals to a module-based system, which is often done in the context of a transition to Ember CLI, which is still changing.
For some context, when we shipped Ember 1.0, we knew that this transition was likely to come in the future, so we took a few steps to help make the transition possible on existing codebases:
- Internally, all Ember lookups go through the Resolver, which takes requests for things like “the post controller” and converts them into a class. In globals mode, that returns
App.PostController, while in Ember CLI, it returns
app/controllers/post. Apps have used this mechanism to flexibly transition even somewhat large codebases from globals mode to modules mode.
- The Ember community has worked very closely with TC39 as the module system has been developed, and Ember App Kit / Ember CLI have figured prominently in the development of modules. That definitely produced some churn as we went, but it ensured that Ember’s needs and evolution were very aligned with modules, and Ember CLI benefited significantly. That process is now underway for classes as well.
That said, the surrounding Ember ecosystem took on the responsibility of experimentation, and as you might expect, a lot of those experiments succeeded! That means that more and more people started to use them, and the “normal” way to use Ember evolved significantly to include these experiments.
As Ember users ourselves, basically everyone on the core team was eager to bring them (especially Ember CLI and Liquid Fire) into the stable set of Ember, and we announced at EmberConf that they would be getting the same stability and incremental updating promise as Ember itself.
That won’t mean the end of experimentation, of course, but it will mean that a larger chunk of the total experience is covered by SemVer and our incremental updating policies. As someone who works on an Ember app (Skylight), this excites me a lot.
When I worked on Rails 3, one of my biggest priorities was looking at what people were doing in the plugin realm and try to provide more blessed paths for common patterns that we would be happy to maintain for the long haul.
From my announcement when I joined the Rails core team:
As of Rails 3, Rails will have a defined public API with a test suite for that API. This was one of the major differentiators of Merb. This will allow users and plugin developers to have a clearer, more stable API to build against. It should also significantly reduce plugin breakage from release to release
I remain a big believer in this. Early releases of frameworks like Ember and Rails benefit a lot from the dynamism of their respective programming languages, but that places a lot of burden on addon developers to maintain compatibiliity for their users when they are forced to dig into framework internals to get the job done.
To be completely clear, I do not believe that addon authors are doing anything wrong when they use private APIs in order to experiment with new ideas. At this stage of Ember’s lifecycle, it’s the best way to try out new things, and provide feedback back into the framework about the kinds of things that need to be exposed more officially.
For me, a major goal of the Ember 2.x series will be to identify and expose blessed versions of the private APIs people are using in their addons. I am eager to work with addon authors to identify the areas most in need of plugin APIs.
I gave Ember Data its own section because it’s been with us since the beginning but has been unstable for a very long time. While Ember has always worked fine without Ember Data, we’ve always encouraged people to use Ember Data, and this has meant that the blessed Ember experience wasn’t nearly as stable as Ember itself.
In part, this is because we never felt happy enough with the status of Ember Data to commit to its APIs, while we did feel happy enough with Ember 1.0’s APIs to commit to them for a while.
In practice, what all of this has meant is that while a big chunk of Ember offered useful stability guarantees and nice incremental upgrades, the blessed path for Ember (Ember Data, Ember CLI, etc.) has been far from stable.
This has been somewhat costly for us at Tilde, but with so much of the full story to flesh out, we always felt that the overall improvements brought by the not-yet-stable parts of the ecosystem were more providing more benefit than the costs imposed by the instability. I’m sure not everyone has had that experience.
That’s why we’ve been working so hard to increase the scope of the stability promises of Ember 2.0 to a larger part of the entire story.
For me, stability without stagnation is a key part of Ember’s mission. While I’m very pleased with the progress we’ve made so far to design a process that can increase stability without compromising our ability to innovate, the job is far from done. I look forward to continuing to refine the model in the 2.x series, and for the Ember 3.0 version of this thread to have benefited from that refinement.
Finally, I also want to be clear about another thing: while I certainly appreciate when people report problems that they encounter during upgrades, I fully understand that people are busy and may not always be able to file bugs. Our SemVer promises are not predicated on you filing bug reports.
The more that you evaluate your applications against the beta releases and report issues that you find, the easier it is for us to avoid accidental breakage, especially in obscure usage patterns. That said, we all take compatibility very seriously and often take great pains to maintain compatibility with private APIs that people report using in practice.
We use GitHub as a rough barometer of practical usage, but sometimes the best way for us to learn that a private API is in heavy use (and therefore we should maintain compatibility with it) is for people to report it.
Thanks for getting through this long post. This community has been amazing at developing an Open Source release model that bends the stability/stagnation curve, and I am looking forward to the next few years as we make it even better.