Is the six-week release cycle too frequent?


The benefits of a six-week cycle are that keeps things moving (“stability without stagnation”). It gets new features/fixes out quickly, and sets pace and expectation.

From my experience, the downsides are that it puts a burden on app (and library) developers to keep up-to-date, and fix deprecations—particularly if they’re not immersed in the community. It also makes it harder to keep the various components synchronised, e.g. ember-cli, and documentation (incl. external blog posts and stack overflow answers), and therefore harder to learn. I think this is also compounded by weekly updates to ember-cli.

Given Ember’s similarity with Rails as an opinionated framework, and the fact that Rails is still going strong after 10 years, maybe it’s worth considering their approach?

DHH explains the Ruby on Rails release cycle in the recent Changelog podcast (at around 1:24:00), simply put: a point-release approximately every 6 months, and major release approximately every two years, and this was based on how previous releases naturally came about.

I think Rails proves that it is possible to achieve “stability without stagnation”, without having very short release cycles.


I think for the immediate future it makes a lot sense to have a short release cycle and I think the main reason for this is javascript.

The javascript ecosystem, both node and in browser, is evolving at a tremendous pace. New frameworks, standards, and best practices are coming out all the time and they’re solving a very rapidly growing range of needs. Until the web ecosystem starts to stabilize I think it’s worth the cost of maintenance in order to stay up to speed.


I wouldn’t consider rails as something that has not stagnated.

As for ember, we are evolving quickly because the ecosystem is still in its infancy. If we release every 12 weeks or six months, that will just result in more Big Bang releases with larger set of breaking changes. As the ecosystem evolves and we circle in on something great these release cycles may slow down. Until then we feel it important to incrementally evolve both ember and the ecosystem at a constant rate. This should break the evolution up in small digestible chunks. Also, we can catch bad choices or regressions sooner and back out or fix If needed


It’s important to note that smaller, more frequent releases actually give app developers more options in how they want to schedule upgrades.

If you only want to update Ember once a year, you can do that. It won’t be any harder than it would be if Ember’s own release cycle was a year long, and in fact it’s still helpful to you that there’s a well-documented series of smaller steps you can use to get from point A to point B, even if you plan to run them all at once in a big annual update.

The important point is that fast releases give you control over how you spread out the work. You can spread it as thinly as every six weeks, or any granularity bigger than that.


I agree to a certain extent. However I think many developers are becoming fed up of the churn, and frequent release cycles and deprecations probably aren’t helping with that. I feel it’s up to framework authors to change this pattern.


Giving developers more options feels like it goes against the philosophy of the framework. The release cycle sets the upgrade expectation, and there’s often pressure to stay up-to-date and to use the latest tools—even if they are unstable. The hype is so great that upgrading feels necessary, not optional e.g. isemberfastyet.

Add-on authors struggle, too: I’ve only installed two add-ons and both have become outdated with recent changes. One broken add-on which hadn’t been updated in 3 months was described as “ageing”! :confused:

I reckon it’d be difficult to upgrade a 1 year-old Ember app today. Given that upgrades be made incrementally (i.e. skipping versions is generally considered a tougher path), a developer would have to go through at least 8 versions before they’re up-to-date. With a Rails-like release cycle, this is just 1 or 2. Then there’s ember-cli and node: should you upgrade those incrementally, too? Whether you should or not, it still pushes the choice on to the developer.

For me, developing with Ember is becoming dominated by upgrade issues, with a significant amount of time being spent reading changelogs, GitHub issues, and Stack Overflow answers, and working out whether or not they apply to my version of Ember. Versioned docs/guides will help, but won’t fix the vast amount of documentation in Stack Overflow answers and blog posts.


to have a more constructive conversation please provide concrete upgrade pain points. At work I am involved with keeping 12 largish ember apps close to canary. One of which is about 70k loc. this helps us gauge the cost of various changes and upgradea. Although there is incremental work required. What we find is a small number of mechanical improvements that helping term maintain ability. Sometimes we run into something rough, report it and we improve that transition.

The only invariant dev"s have is change. Let’s make change as easy as possible. Maybe you have some concrete ideas how to pave this path.

The one thing you point at that is absolutely true is ember-cli. It just isn’t stable yet, unfortunately in its current form it is still the best option we have. We hope to have a 1.0 beta by June 12th. Once we hit stability we will drop in the semver constraints. Unfortunately, we have some big tasks ahead of us and we will do more harm long term if we don’t iterate now. This is to get ember-cli to a place where we feel comfortable with the defined public app and addon API’s.

As you hit pain points when upgrading. That includes confusion, report a bug. It is possible we missed something. At the very least it will result in an explanation/clarification and future travelers will likely also find the conversation helpful. Worst case it is duplicated and we can link to the resource that explains it.


Hi Stefan! I think that given you are a core team member, maintaining 12 canary apps may not be a realistic gauge of the issues that many others face. This was highlighted when Tom and Yehuda ran workshops in the pre-1.0 days.

It’s difficult to detail precise pain points. I tend to upgrade ember-cli at the same time, so perhaps therein lies the problem, and I’m confusing the two? My recent pain points have mainly been as a result of the 1.8, 1.9, and 1.10 upgrades, but I’m never quite sure which part of the stack is responsible: it is an ember issue, or an ember-cli issue? Going through Stack Overflow questions, and GitHub issues usually comes up with a solution, but it can be time-consuming, and it can often feel like a temporary hack.

(Aside: With ember-cli, ember’s dependencies now feels quite weighty—node/io, npm, bower, broccoli, qunit, jshint—most of which are not controlled by the ember core team, which can lead to unexpected changes to workflow. e.g. QUnit syntax changes.)

Just to reiterate, I think my main issue is that the faster things move, the faster things goes out-of date, the more work has to go into keeping up-to-date, and the less productive one becomes. In particular things like:

  • Guides
  • GitHub issues
  • Stack Overflow answers
  • Blog posts
  • Add-ons

If content from these sites could refer to any one of 8 or 9 versions in the last year, then learning is not going to be easy. From this perspective, so it’s not surprising that the documentation remains a frequent criticism.

Frequent additions and deprecations add to the (already steep) learning curve. Concepts that developers have spent time learning and mastering, begin to disappear, which is obviously frustrating.

I appreciate the work the community does to get releases out. I also appreciate the eagerness to get releases out, particularly given the current framework landscape, but I think it’s rate-of-change may be affecting productivity. My feeling is that six weeks does seem a bit extreme (and Chrome doesn’t seem to be the most stable software right now). Having said that I’d be happy to accept that I’m wrong :wink:


I’ll be brief since my perspective likely is not realistic either.

Yes, this was more troublesome than earlier version updates mostly because the templating engine changed in each of them. This does not help at this point, but the current setup (post 1.10) provides us with the ability to completely change the template engine again with little to no compilation process changes.

As mentioned by @ef4 the release cycle does not dictate the speed of changes. The work is happening either way, and releasing less often would simply mean much larger changes between versions.


One thing which I think has been hurting me is like @stefan said that ember-cli isn’t stable yet. The upgrade docs are much better than most application upgrades however all the bugs I have raised have been around edge features in the app.

So for example (ones I can think of quickly recently):

  • Using a root level proxy for testing
  • Glob npm update issue
  • Using a URL prefix whilst supporting IE9 directly loading the URL’s
  • Using marked with ember-cli and using a URL prefix for the app.
  • Using Ember.A methods on a belongsTo relationship on ember data 1.0.0-beta.14 for example just doing this.comments.length in a computed property silently broke
  • Upgrading to ember data 1.0.0-beta.15 and having my own serializer.

All the while I have been wishing for a LTS Ubuntu style release, however then part of me thinks that would stagnate development whilst it seems like Ember goes through some crucial stages of shaking off older code.

So I have held off making any noises in this direction until I have a stable ember-cli and ember data as I don’t know if having the long term support solutions will help. From a security and stability stand point I think it will; my worry however it would fragment the team too much further stagnating ember.


Semantic versioning has been maintained though, right? Your Ember 1.0 app will still work in 1.10. That’s all LTS really gave you- they didn’t promise when Sublime 3 would have a stable version in apt.

The problem is that Ember data and CLI are considered core parts of the framework by everyone, but are very much just Some Tools that Some People came up with. The reason that they (and liquid fire) are getting rolled in isn’t a result of broken promises by the core team, it’s a result of their psychopathic embrace of community development.

If you bought a book on Ember 1.0 and developed an enterprise app based on that, it will still work. If you’re complaining that you have put some work in to keep up with the bleeding edge, you probably shouldn’t be on it. If you’ve confused about where to start, we know and we want to help- it’ll be a little more clear in June, but you’re starting at a perfect time. What questions do you have?

</self-appointed-spokesman lol-with="@tarasm">


Sorry, I didn’t mean to imply that core team members’ perspectives are not realistic, but rather that the pain points of someone who is fully immersed in the community, who knows what’s going on and where the problems might lie, will be different to those from someone on the fringe.

Great to hear! :+1:

The release cycle may not dictate the speed of changes, but there is a certain level of hype and expectation that surrounds each release. The isemberfastyet site is an example I mentioned earlier. To me this says, “upgrade ember and your apps will be fast”, which carries quite a lot of weight!

I have no qualms about small, iterative releases. I think it’s a good thing, however I wonder if a longer testing (beta) period might help? That way developers on the stable channel will be using concepts that are more thoroughly tried and tested, rather than being exposed to choices that may have a relatively short lifespan.


In principle, yes. In practice, I’m not so sure. You’ll be swiftly encouraged to “just use ember-cli”, which is a significantly different approach.

Sorry if it has come across this way. I am proposing a slower release cycle which aims to reduce the frequency at which developers have to adapt to change. If developers shouldn’t be on a stable release, then there should be less pressure to upgrade.

I started about 3 years ago, and it’s felt non-stop ever since! :sweat:


Of course, a large part of that is because we are adding features (and fixing bugs) that folks are excited about. There is nothing requiring folks to update ASAP everytime a new version is released. BUT we certainly hope that you are able to do the upgrade without massive pain…

It is my perspective, that we do not have enough users that test the beta series in general. Almost as if the perspective is:

“Lets let other people test it on beta and we can stick to the release channel”.

Making the beta’s longer will not encourage folks to use and test them.

Also, as an aside, we have not (to my knowledge) released a version where issues were identified (during beta or canary process). The single best thing anyone can do for stability is to test and report issues.


What if “beta” was renamed “release candidate”? Subtle, but may push a few more users in that direction


These are all from either Ember Data or Ember CLI, not Ember itself. Neither Ember CLI or Ember Data are 1.0.0 yet, and neither of them follow a 6 week release cycle (which I thought was the point of this thread).

Both of these projects are striving for stability, sadly to get to the best possible API’s and result we likely will have to have breaking changes…


Maybe, but I doubt it…


Given that Ember is marketed at increasing developer productivity, I think developers would rather be developing their apps rather than testing beta versions of a framework.

Starve ’em of a release for a few weeks/months and they’ll be gagging to test a beta version! :wink:


Seems fine, but then clearly longer beta periods would not help.

It has been mentioned in this thread a few times in other ways, but there is no invisible force that will take your application and make it stop working if you don’t upgrade immediately. (I promise)

With the release cycle that we have, when and how to upgrade is completely at your discretion (as it should be!).

  1. Want to stay relatively close to newer developments? No problem, just update when the new releases come out (hopefully after testing a beta or two).

  2. Don’t like dealing with Ember upgrades every 6 weeks? DON’T! Just upgrade when it works best for you and your team.

That is the beauty of the process that we are in. Having more frequent smaller chunk releases, enables both of the above scenarios. If we only did one bigger release every 6 months or so (spaced whenever we feel like it) you have nothing to satisfy #1 above.


It’s a tough one. I seem to remember that there were a lot of developers using canary for the query params feature. This was obviously a biggie, offering great value immediately, where developers might be willing accept a few edge-case bugs.

With small iterations, the updates might not be so “big”, so there is less of an urge to try the beta channel. (I don’t mean any disrespect with this–e.g. the HTMLBars work looked massive!) But developers might be happy to wait for the stable version rather than try something which doesn’t provide immediate value, and may break.

I wonder whether my feelings of being overwhelmed by updates come down to community hype. Many community members advocate/hype the use of unstable tools. The “ember way” changes so often, which makes learning and using the framework quite difficult and frustrating. Off the top of my head:

  • use ember! (pre-router rewrite)
  • use ember-data!
  • views are old hat, use components! (v1rc-6?)
  • use ember app kit!
  • ember app kit is old hat, use ember-cli!
  • bower is old hat, use npm!

These changes are of course beneficial in the long run, but if you’re trying to follow along with “best practices”, it’s frustrating. (Though this is perhaps one for another topic.)

For me there is a feeling of being left-behind if you don’t update. It feels counterintuitive, but I’ll have to learn #2!