Is the six-week release cycle too frequent?


Although I agree that the upgrade process is not pain free at the moment, I’m not sure if Rails style release cycle is a good alternative. With a big Rails application it may take a few weeks or even months to upgrade it to the newer version and some apps are just declared unupgradeable (ie. “the cost of the upgrade would be too big”). This was especially visible between Rails 2.x and 3.x, but I know teams that struggled a lot even with later updates. There were some efforts to create a decent upgrade path, but with the scope of changes, both for plugin developers and for end users, it was extremely hard to upgrade some of the apps. I believe it would be much easier to upgrade large apps with gradual changes, just like in Ember.js

There was also a point about a pressure to upgrade. Personally, I really want to stay up to date (also to start helping Ember team), but I haven’t found time to do that yet and that’s fine too. I was usually upgrading a few versions at a time and it was relatively pain free as long as we were not doing something really weird with low level APIs. Travis CI is a really old app (it started as an Sproutcore app), so there was a bit of refactoring needed, but it took days rather than weeks or months.

The biggest upgrade for me recently was a switch from a custom rake-pipeline based build tools to ember-cli, but that, too, was a matter of about a week (and in the process I was also cleaning up the code a bit). It may seem like a lot of work, but I believe Ember.js has the best CLI tools at the moment, so it was well worth it. I’d rather have such “problems” than a ‘no unified tools’ problem.

I should probably add that I write this as a person, who knows Rails internals quite well (I have contributed about 600 commits). Even with that knowledge it took me up to a month to upgrade one of the apps I got to work on from 2.x to 3.x


CSS WG list of mistakes is a list of changes they would implement if they could, however this to me matches with what @2468ben was mentioning.

Due to the much faster pace of Ember than CSS is, I feel this would be something that would be a good resource to have that should be correlated into one central place.

The big release announcements at EmberConf are brilliant to build up interest however before things have solidified as ideas. The pain points which are likely to change should be mentioned in this document. For example routes cause state based issues we will be moving them to something stateless soon (Then once routable component idea happened the page could link to the RFC). I also think the duplication of messages would better target the different audiences that Ember has.

So things like, try to avoid ArrayControllers because they are being deprecated soon. HTMLBars will change x to y so step carefully around this area.

The page can be a very cookbook style draft but it would save developers of doing the checking mentioned by @2468ben.


I think this was one of the biggest points that pulled me away from suggesting Rails in a commercial setting, companies get out of sync pretty quickly and upgrading from PHP4 to 5 and Rails updates are really something that gets put off until it’s urgent.

Certainly the big bang updates to a backend is not something that bigger companies want to swallow at all. Everyone must have seen the server that no one is allowed to touch as no one knows how to fix it syndrome.

With that however almost the opposite is true of the front end, when the backend is glacial due to high risk I feel the pressure is always on the front end to be agile and progress products fast.

I feel like this might be directed at me, certainly I have felt that but mostly whilst I am in the shadow of the beta Ember data and 0.* ember-cli.

But I can see this setup of smaller iterations working, I’m just a little sceptical up until I see it working (I’m sceptical of everything - I’m a programmer).

I guess this is just something that as Ember evolves it might become more important that there is something that caters for Enterprise better. As @trek mentions this could be something a developer picks up as and when it is found to be important enough - I get the feeling however that companies will just shadow their own package tracking with their own forks etc internally on their own servers.


So, if the Ember and Angular communities represent fairly opposite approaches on this, who’s 2.0 announcement was more warmly received? Both of us are going to have great new versions, and both of us have 2.0s that are nigh-unrecognizable from 1.0.

Angular is having to back pedal now because they ruffled too many feathers with their big bang announcement. This thread notwithstanding, I think the overall reaction to Ember’s new approach has been incredibly positive. I don’t think it’s just because we’re “better”- I think it’s because it all happened so organically that there wasn’t much of an argument to have. The reason CLI is so standard now wasn’t because we all had a vote and decided we needed build tools. Some incredibly smart and dedicated folks just made build tools, and they became popular because they were good, and they’re becoming standard because so few people want to work any other way.

Overall, it’s hard to say what’s actually going wrong because some of the issues brought up in this thread are actively, hour by hour being addressed. The docs are being changed to reflect CLI, Ember Data will hit 1.0 soon, everyone’s release cycles are about to sync up, we’ve committed to versioning the docs… There’s never been more work going on to address some the very valid concerns that have been brought up.

I think all of this happens because of rapid release, not in spite of it. The downside is that you cannot really ever say “I know Ember.” It’s a moving target. I don’t think I’d ever trust an "Ember Certified Developer" certificate. You need to be a part of the conversation to be a successful Ember dev. That may turn some people off, but I think it’s our greatest strength.

If you haven’t, I’d highly recommend watching Chris Eppstein’s closing keynote from Emberconf. It was a little strange while it was happening, but I haven’t been able to get it out of my head since. We don’t need to be everyone’s solution. We don’t need to “win” the framework wars. We just need to make tools we like. Maybe that has to come at the cost of not being a good fit for every use case.


An unfortunate side-effect of Ember’s 1.x globals-based namespacing is that many things not intended to be public are in practice public. Limiting the API surface in 2.x (now that we have modules-based namespacing) will focus us on providing the right surfaces needed by both consumers. I really don’t expect the needs are very different. We will have the tools going into 3.0 to better insulate consumers from internal curn, in many ways.


I remember that in Merb (also maintained by @wycats!) there was a rule that any private API that’s needed for a plugin is a bug. Maybe it would be good to add it to Ember too?


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.

Surrounding Ecosystem

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:

  1. 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.
  2. 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.

Ember Data

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.

Bug Reporting

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.


Yes. I would consider any private API needed for a plugin as a bug. Please file 'em!


Can you elaborate on that a little - what exactly do you mean by that?

I have a plugins targeted towards HTMLBars that uses private(ish) APIs to deliver unbound helpers (_registerHelper and streams) but I assume I only need to do that because HTMLBars is new and you guys haven’t really locked down how you want to allow unbound helpers - would this be considered a bug as you mentioned?


You’re exactly right for why this is the case. I’d still consider it a bug, though maybe one people can be a bit more patient with as we are still trying to figure out the best APIs. :slight_smile:


Hey All.

I haven’t been super active in these forums but actually came by yesterday to gripe about some of these exact things :slight_smile: This thread caught my eye and I have spent the rest of the time reading it. Some of these things I have probably griped about in detail to some of you personally before – hi @lukemelia and @mixonic :slight_smile: I am obviously thankful for Ember and all the work that everyone has done, and feel passionately about the fact that it could be made even better, so please don’t take offense to anything here.

By way of explanation, and to mirror what some others have said in this thread, there is a group of users whose issues are being ignored because of the current makeup of the core team. I took a peek and as far as I can tell @machty is the only core team member that appears to be working on a small product team, most everyone else is a full time ember consultant, with a couple working in large orgs. My experience mirrors almost exactly what @domchristie said here and@2468ben said here. You are missing the perspective of a key constituency who is using your software, and betting their businesses and careers on this community’s success. I don’t think this means you put real representation of us ‘amateurs’ into core necessarily, but perhaps some other mechanism can be found to alleviate this blind spot.

Like many in this community, I came from the Rails world. I have been using Ruby and Rails since pre Rails 1.0, so have gone through a lot of transition there. I have used just about every other Ruby ‘framework’ as well (merb,sinatra,grape,webmachine,etc). None of the pain around big bang releases, or the introduction of concepts like Bundler and rvm in Rails compares in any way with the magnitude of pain currently experienced by Ember programmers trying to use this framework for professional work. Yes, bundler and rvm were rough in the beginning and if you were upgrading from rails 2->3, 3->3.2, or 3.2 -> 4 it was a significant effort, but it was doable, and totally possible to put surrounding issues in the rearview mirror once complete. We have 2 relatively normal (from my perspective) Ember applications, 1 is in production, with the other one going to production shortly. We also have several ruby/Rails applications in our list of responsibilities, and I manage the team. This means that I don’t spend every single waking moment reading about Ember and scouring the internet for changes and quirks that have happened. Right now I probably work on our Ember applications 4-5 days a month in aggregate, and I am spending > 50% of my time dealing with platform quirks (ember-cli, npm, bower, builds, etc) instead of writing application code. Literally, every time I pull our app from the repo after leaving it alone for a few days or a week, there is a build issue somewhere in the stack. When this happens my instinct is to think: “Hey, maybe I am just out of date and I should upgrade the entire world?” (ie, ember, ember-cli, our various dependencies). This never works, because the same problems exist in every other layer of the stack, and you just get all of them at once. The resolution is alway sitting in some obscure corner of the internet, the 5th hidden comment on an SO question, or deep in a github thread that I find 5 hours later.

For example: On the glob issue referenced beforehand, which we also hit, you need to read a voluminous amount of info before you can decode the fact that the comment by SeanK here is the actual resolution to your problem. I probably looked at this specific SO thread 5 times before it clicked.

I will say, for me almost none of this pain comes from changes in Ember itself (I think), but from the current state of the ecosystem. However, like many have stated here I have no idea that that is the case because I actually can’t tell, because it’s so bad and so overwhelming that blaming the release cycle actually seems reasonable to me (sometimes).

Where we stand:

@wycats your summary of the situation is excellent, and calming in your usual way, but it leaves out a big piece, which is what is the core team going to do about it right now and where should everybody on this thread put their energy? There are decisions that we can make right now, and don’t need to wait on or be pushed under the rug again. Specifically I think there are a couple of dangerous “memes” which get repeated by some when issues like this are brought up as a way to deflect. I even came up with cute names for them :slight_smile:


  1. The Well Actually: “Well actually, Ember itself is totally stable and follows SemVer, your issue is with X project”
  2. The It’s not me It’s You: “The fast release cycle minimizes work for all of us, maybe there is something wrong with you/your team/the way you work.”
  3. The You Don’t Have to Use It: “You could just freeze your app on INSERT VERSION HERE, and you’d be fine.”

In order to move forward (and be successful), I think now would be a good time for everyone on core to realize this is what it sounds like they are saying to certain criticisms, and hopefully spend some more time thinking through some of these issues. A plan and a commitment to resolve the concerns would go a lot further than honing these arguments to sound better.

I think everyone probably knows that the title of this thread and the release cycle in and of itself is not THE ISSUE, however I do think core team members and others who are not hitting the “Scour the Internet” sandtrap are failing to realize one thing about it. The release cycle currently compounds all of the other ‘real issues’ discussed here. We are not in a stable system, where this is the only change, and the current release cycle contributes to a cognitive dissonance that makes application programming in Ember much more painful than it should be.

This does not mean that we need to change the release cycle right now, for me it just means more effort needs to be put on the real issues raised here (and less effort potentially on new features). I do think layering a LTS plan on top of the current structure and committing to LTS of 2.0 are great ideas I would likely support. I think they would go a long way towards making people feel more comfortable adopting Ember long term.

In the spirit of constructiveness, and brainstorming ways to actually fix this stuff, here is my off-the-wall proposal:

  1. Defacto components of the ecosystem need to be included in the release cycle. When non-power-users say “Ember” this is what they mean anyway (whether core likes it or not at the moment).

    • Ember becomes a meta-project
    • Ember CLI and Ember Data (I will gripe about this in a different thread), along with a new Ember Core (current Ember) become dependencies of Ember (the meta-framework). This mirrors the project structure of Rails (which includes ActiveRecord, ActionController, etc)
    • This paves the way for breaking up other parts of Ember into standalone libraries as they mature.
    • If effort on feature work needs pause in Ember Core when necessary to get fixes in for these other required parts of Ember, it can.
  2. Ember needs to own responsibility for the ecosystem:

    • NPM and Bower have a horrific user experience when coming from the stability of Bundler. If Ember CLI and the ecosystem are going to depend on them then we need to wrap and hide their warts (ember server, ember build and ember install should do the right thing). Issues that these projects should own, should be fixed locally, and pushed upstream if possible.
    • In order to actually fulfill the SemVer promises, more real apps need to be tested in a repeatable way. Start a (potentially secure/private) registry of ‘donor’ applications with test suites. The scripted upgrade (currently ember init) must apply, and must pass the application’s test suite, or its a bug. This will drive ember init to actually be usable as well.

I will reiterate that what those working actively on Ember have built is amazing and the main reason I ever even took a look at it in the first place was because of all the amazing people I knew working on it. I think if we can get this part of the story right, it will be by far the best front end platform to work on. Thanks for listening.

Edit: list formatting


Just wanted to add in my two cents, which is that I really value the consistent release cycle of Ember. The idea of iterative progress where we can slowly refactor to continually changing practices is so much better for my teams than a big-bang slow upgrade process. My engineering teams all run Scrum-based with two to four week delivery periods, which means its easy to consistently bring in Ember upgrades to the process.

A longer release cycle for us would mean we couldn’t keep upgrading as we delivered new product functionality and would have to get product approval to do major upgrades. I think for people who want to wait for major upgrades, this consistent cycle already supports that well, and for those of us who are Agile, this fits well in our process.

Woudn’t change a thing.


With regards to Ember (“Core”) releases, I think we are discussing two different variables:

  1. The size of Ember releases (e.g. incremental vs big bang)
  2. The frequency of Ember releases

Note, the question isn’t “are Ember releases too small?”, but rather “are Ember releases too frequent?”. As I have mentioned, I am not opposed to small, incremental updates, but can feel overwhelmed with the pressure to keep up-to-date, which might be caused by the high frequency of releases.

I think we’d all agree that frequent “big bang” releases would be disasterous; and infrequent small releases could result in stagnation. So there is a balance to be had. If you aim for a high frequency, then you must carefully ensure that the size is manageable. From this perspective, the six week structure works well as a limiter, preventing the magnitude from becoming too great.

However, a high-frequency release cycle can give the impression that the framework is unstable and needs updating, putting pressure on developers to do so. For the most part, I’ve not felt this pressure with Rails or jQuery. This might be for a number of reasons, but I feel the release cycle could be one of them. With Google Chrome, the six-week releases are silent. There is no upgrade pressure.

I don’t think that a slower release cycle necessarily means bigger changes. The same “size” changes over a longer period might allow more time to improve the quality, and reduce the strain on both the users of the framework, and the developers behind it.


I took a peek and as far as I can tell @machty is the only core team member that appears to be working on a small product team, most everyone else is a full time ember consultant, with a couple working in large orgs.

This is completely wrong. I am a team of one responsible for an entire ambitious Ember app. Tom and Yehuda’s main product is an Ember app built by a small dev team. Martin and Kris also both work on small product teams. Stef just left a small team to go to a much bigger one, but even now he’s helping keep several very large apps up to date with canary. Robert works for a consultancy but spends vast effort helping other projects like Ghost and Discourse deal with long-term support & upgrades.

I have shepherded the same codebase all the way from Sproutcore 1.6rc2 to canary. While trying to built a startup, as the only technical person on the team. And the product needs to always work, because it’s a medical app. So there is absolutely no support & upgrade pain out there that I haven’t experienced and directly worked to improve.

This idea that we don’t understand the realities of working on small product teams is nuts.

Like many in this community, I came from the Rails world

Me too, and part of the pain you’re experiencing is that the wider Javascript ecosystem is a mess. There’s good engineering out there, but it is floating in a sea of crap. Ember is an island of good engineering, but we constantly battle with the suckage of the wider ecosystem, where people still need to be convinced that “abstraction” is not a dirty word.


@jakehow, thanks for your post. It definitely gives me some food for thought. Just wanted to respond to one point you made.

Many members of the core team work on small product teams:

  • @tomdale, @pwagenet and I work on Skylight. Skylight started out as an early, globals-mode app, and we’ve upgraded it throughout. As I said in my post, we’ve definitely experienced the costs of these upgrades, but like you, we have very limited consistent time to work on the Ember app.
  • @mmun works on CrowdMark, which is also a small-team project.
  • @ef4 works on BraveLeaf, a small project
  • @krisselden works on Yapp, and until recently @stefan worked with them
  • @machty works on Express Checkout, as you alluded to

Only a small handful of us work on large teams or as full-time consultants. I wouldn’t have it any other way.


I have been reading this thread as it evolves. I guess what I don’t understand is this, why can’t you just set a policy to only update ember dependencies every X releases within your own organization. What is the pressure to update sooner unless it is for performance or features that you want? If that is the case why in the world would you want to wait for them?

We have a policy that has kept us using ember canary releases within hours of them coming out but as we near our own release we stop doing that and stay on a stable or beta release that we feel is well tested for our app.

Our next sprint includes time to catch back up to canary, ( a couple hours) and then we are back in business on the edge until our next release nears.

I would hope that the 6 week release cycle stays in place, I think it suits how many of us manage our own projects and still gives those who want to update less frequently the option to do so.


@ef4 Sorry to offend. You were the only person who I didn’t know where they worked :smile:


@wycats thanks for clarifying this is part of the core team strategy. Tilde and Yapp (Labs) are both ‘consultancies’ in my mind. @lukemelia can probably clarify, and I admittedly don’t know how you split your time between work on your own products vs consultancy and training.

Also, I didn’t mean to imply that the dichotomy is between small and large teams but between people who are completely immersed in ember vs those of us who are spending some much smaller percentage of their total workload on our ember apps and having trouble just trying to keep our head above water.


@jakehow The Yapp/Yapp Labs team is 4 engineers and spends approximately 3 days a week consulting (Wednesdays through Friday), and two days a week on the Yapp product (Mondays & Tuesdays and when we don’t have client engagements). We maintain 3 desktop-targeted Ember apps, plus a Cordova/Ember mobile app, the medium-thickness iOS and Android wrappers, and the Rails-based API behind it all. Man, I’m exhausted just writing that.

Upgrades have been a challenge for us (we currently have apps at 1.6, 1.8.1, 1.10, and 1.11-beta) and I’ve felt a lot of the pain you’ve described. Like some others have mentioned, most of our upgrade challenges result from unstable dependencies that consume private API in Ember (list-view and draggable-each come to mind) which changes over time. I think it is really hard to navigate these waters currently without either a) limiting yourself to only very stable stuff, i.e. Ember core, or b) having at least one member of your team who is immersed in the Ember opensource ecosystem.

There is a pattern in the community which has been fairly consistent – someone (often Stef!) begins trying to solve a hard problem (like build tools, data layer, virtual list views, etc) and clearly labels it “THIS IS NOT STABLE YET.” A subset of the community jumps in anyway because the pain of not having a community solution to the problem at hand is so large. The subset then has some combination of genuine productivity gains, excitement about the progress, and Stockholm Syndrome, and shares their glowing report with others, who also decide to jump in despite the warning of instability. The vision of “Ember” expands, and with it the milestones necessary to reach stable solutions. You can read that as a critique, but this kind of innovation and excitement to collaborate is a huge part of what I love about the Ember community. It’s also the reason the ecosystem has come so far so quickly.

I think this is a great discussion and touching on real pain points. I’ve seen first hand that the core team and many extra-core contributors are keenly aware of backwards compatibility and upgrade paths. I think there are real tradeoffs between stability and innovation, and I’m hopeful that getting ember-cli, ember-data, list-view and liquid fire to 1.0 in June is going to help a lot.

Some things I have found useful to deal with this myself:

  1. upgrade ember-cli and and ember versions independently of each other.
  2. make clear choices within your team about whether a problematic dependency is important enough to keep and decide to a) replace it, b) invest OSS time into fixing & improving and/or c) invest money into paying someone else to fix and improve it.
  3. emphasize acceptance tests over unit tests – they are more likely to be useful in upgrades and less likely to break
  4. if you begin an upgrade and discover a blocker or major piece of work that can be refactored in place, consider delaying the upgrade and instead perform the refactoring in your current version to be better prepared for the upgrade and reduce scope of the “big upgrade”.

I would love to see someone in the community develop an easy and conventional way to automatically run our test suites against canary or new betas so that teams have an ongoing sense of how broken their app is and can give feedback earlier in the beta cycle.


This would be huge and I have been noodling on this for some time, I believe we can doit. The current barriers I see basically boil down to a single lynch-pin client side dependency management is broken. As we improve this, the above goal becomes more and more a reality.

In the ruby world, I use the appraisal gem to help enable this. I suspect, it is something we can also strive towards.

It might sound crazy, but based on the general tone of this thread, I believe no-one would be surprised to know that at-least 30% - 40% of all ember-cli bug reports or SO posts are directly or indirectly related to the dependency management story.

I have to say, even though I apparently have lost touch with reality this is also something that constantly burns my time, when working/upgrade/debugging ember apps, never mind the over-head related triaging ember/ember-cli issues has. So I suspect my reality is sufficiently compatible for the time being. Maybe once we solve this, I will ascend to some plane of existence where software writes it self, deadlines are always hit and npm ls glob returns something reasonable.

Joking aside, the dep story is hurting us all.

Amen, and even though we are out of touch this is something we have been and are working towards.

Reality kinda sucks, as It isn’t simple building on the unstable foundations that currently exist. In addition, it posses an extremely complex upgrade path problem. Which will likely cause other pains brought up in this thread, that being said I personally feel those pains will be well worth the rewards. Minimizing them will be key.

Basically, the current effort on this topic is as follows:

  • drop bower entirely
    • no solution is solved better with 2 package managers
    • the project itself is basically defunct
    • choose your own adventure resolution strategy is worse then no resolution strategy
  • work with the NPM & Angular team to:
    • solve existing bugs
    • identify major problem points
      • shrinkwrap.json is broken (we need Gemfile.lock semantics)
      • client-side deps are essentially not supported (the dupe based resolution strategy is not compatible with client side resources)
    • many other things, but I – and i suspect most community members – will be extremely happy if we can solve ^^
  • push the client-side dep on npm story forward
  • refactor ember and it’s micro-libs to be better client-side npm package citizens. (note: no more bower)
  • enhance ember-cli to automatically take advantage of ^

Interestingly if anyone feels up for the challenge I know that google is looking to hire at-least one person to help work on the client-side NPM dependency problem. If someone feels confident they can make a difference, and it interested. Please reach out to me, I would love to connect the dots.

After reading and digesting this thread. It really just feels like we all actually have the exact same pain points. Merely some view it from different perspectives. Context or the lack of context can drastically change opinions on a topic. To claim the problems exist, due to some being out of touch with reality isn’t productive, the problems exist largely because the client-side dev eco-systems immaturity, and time being finite resource.

The obvious solution is to continue to band-together, and collectively move the eco-system forward.