https://github.com/kategengler/ember-try is a great new addon that makes testing an addon/app against various Ember versions as simple as ember try:testall!! It is still in active development, but I am super excited about it…
3 Likes
its really natural tension, finding that balance is really hard.
I found a post on @wycats’s blog talking about the very same thing with Rails 3. One of the comments concludes:
Microsoft eventually moved to a minimum 5-year release cycle of major version upgrades, with only relatively minor upgrades in between. 5 years may be far too long, but 6 months is definitely too often.
Release cycles appear to be getting shorter and shorter! Who knows, maybe when vapor.js announces it’s hourly release-cycle we’ll all moan that Ember has stagnated 
@stefan In terms of striking a balance, it is hard, which is why I suggested considering Rails’ approach. To remain so popular over such a long period of time (in modern software terms), they must be doing something right. That may not mean that Ember uses the same release-cycle timeframe, but perhaps something a bit more flexible? (Unfortunately I don’t have any concrete ideas other than to copy it, but hopefully this discussion will spark off some creativity!)
I feel like Ember has more in common with Rails that it does with Google Chrome. Chrome is, for the most part, a consumer product, which does not present its users with new concepts/deprecations every 6 weeks. The recent Ember changes maybe a lead-up-to-v2.0 thing, but they highlight the point: a fast release means that concepts may change in a relatively short timeframe, (and can be deemed acceptable under the SemVer promise). The user-facing concepts of using Chrome haven’t changed much at all, which means they can automatically roll-out updates with ease. This has also made their version numbers pretty irrelevant, too (who tracks what version of Chrome their on?).
Whilst I appreciate the aim of matching Google’s approach, the differences in the final product seem significant.
1 Like
I suspect for each post like this, we would also see one from the other perspective if ember didn’t improve and didn’t fix bugs as quickly as it does. The same features you are upset about breaking or changing, are the same ones that wouldn’t exist if we didn’t move forward.
As mentioned above, innovation has to happen somewhere, if someone is un-interested in participating sit back, stay on 1.0.0 and wait for 2.0.0 to upgrade. Or some other interval that works for you. You cannot both get the incremental improvements and complain about them.
The path forward is to derive methods to reduce the cost of innovation, but it absolutely just can’t be to stifle it.
As I have said a couple of times, I’m not opposed to incremental changes, but rather to an overly-aggressive timeframe—and I don’t think that a longer timeframe will necessarily stifle innovation. I’d hope that it would lead to more solid and considered ideas, reduce the need for developers to adapt so frequently, and therefore allow them to be more productive.
As Mae West once said:
Anything worth doing is worth doing slowly.
@stefan thanks for the details in your earlier post about specifics that are being worked on that really helps.
The only reason I think that talking about perspective matters is because it leads to a little more consensus on priorities. I now have a much better understanding that you are ‘supporting’ a lot of these complaints that come in as issues which I am sure is a big burden. I hadn’t really thought about that too much before I wrote my post.
The performance issues that prompted the work on Glimmer were obviously showstopper level ‘bugs’ for a certain class of applications. I am unsure of how to explain to you that the issues discussed in this thread are on that level for us without explaining our perspective.
These sort of architectural and foundational things are pretty hard to help with from the outside (we already buy consulting time from core contriubutors which I am sure they use to offset the ‘free’ work they do in ember), so if there are other ways that people can contribute to ending these problems, we need to be pointed in the right direction.
If this is the recommended strategy for dealing with the current situation, we need two things to make this possible:
- repeatable builds
- a significant portion of the community doing this so that we can support each other.
From my perspective the changes are actually pretty incremental, just high frequency. The changelogs for the point releases are typically a few new features and a lot of bug fixing and refactoring. The problem is that staying on old point releases is not currently viable because of the two issues above. If you could get those two things and wait 3 or 6 months between upgrades would that solve most of your issues?
Some of the lines in the changelogs are unlabeled ( I am guessing these are refactoring?). Potentially every sort of change should have a tag in the changelog to make this a little clearer. Updating dependencies may be pulling in new features as well.
@stefan thanks for the link to @katiegengler’s lib. That seems like a solid starting point for getting more complete testing of real world apps against changes in ember/ember-cli.
Are there other links people have found that might be places to point effort and energy? I noticed there is a Roadmap issue on ember-cli here: [DISCUSSION] Roadmap · Issue #2997 · ember-cli/ember-cli · GitHub
Also it seems like changelog mentions are always pointed to related PRs as of 1.11 
Yes, it is quite a bit of work, so I’m hoping that it is helpful to folks…
It depends on how the framework is used and its reputation with respect to stability (or availability of stable releases). I don’t really want to adopt a js framework that is even more unstable than the main application framework (say Rails) it is supposed to complement, and mixing two complex frameworks is already very risky.
If anyone hast any tricks they are using to get idempotent builds (or close) I would love to hear them. Started a new thread here → Are idempotent builds possible?
Coincidentally, I was chatting about this topic with some folks the other day.
We were all devs who believe strongly in shipping continuously to our clients, but asked the question, “would we really want the same thing from the frameworks and libraries we depend on? Is there something different about framework-y code where shorter release cycles can actually be a problem?”
We started talking about how the majority of time spent dealing with framework code is split up among:
- gaining a high level understanding of the framework
- keeping up with changes and deciding when to pull them in
- updating individual dependencies when necessary, and dealing with incompatibilities occasionally
- searching google, forums and stackoverflow for specific answers
Number 4 is the one the generally eats up the most of our time when dealing with any given framework. We discussed some of the challenges of finding the right answers to questions in other frameworks we are using in current projects. In general, the feeling was that its much easier to find the right answer to a problem in opinionated frameworks with a certain amount of stability.
In other words, these three things all have to be true:
- Is this the same question?
- Is this the right answer?
- Is this answer relevant to me?
Opinionated frameworks increase the odds that the question is the same, and that the answer is correct. Stable frameworks increase the odds that the answer is still relevant.
Unopinionated frameworks greatly increase the time it takes to find a good answer.
I think that frequent changes also make this “find the answer I’m looking for” game much more difficult - and this is the biggest risk of the model.
It may be too early in Ember land to do this right now, but one possibility to keep in mind going forward is to have some kind of LTS release in addtiion to frequent, stable releases with new functionality. The LTS release would allow a critical mass of users to build community knowledge around a given version of the software over a period of time. The frequent releases would continue to allow an early adopter community to thrive and prove new features.
These three ideas really struck a chord with me as well:
In other words, I think the project could benefit from longer cycle synchronization points that the community can rally around and better support each other without having to upgrade to the latest stable release.
It seems like this sentiment is somewhat in line with the keynote from this years emberconf, but perhaps it should become a more conscious aim of the project for future major releases.
2 Likes
Ok, how about this: Would anyone like to work on a little Ember site that scrapes/api-calls a bunch of these different sources and shows some recent lists on one page? Sort them all by date, filter and search too where we can. Then if you have a question about X you can get a wide variety of recent results without opening N tabs. Or if you’re like @stefan and want to save time looking for questions, you can see a lot of the latest ones in the same tab.
Google, Github issue/PR comments, Stack Overflow, discuss.emberjs.com, twitter, and whatever else would put up with it.
(Motivated by Godfrey Chan’s great talk Hacker News).
this may be related to the ember-weekly ember grep stuff, I believe the aim to have an aggregator for news, maybe it can also be questions?
cc @tarasm
EmberWeekly/EmberWatch/EmberFlare & EmberSherpa are starting to work on this. Would you like to help us make it happen?
2 Likes
and yes, i would love curated questions to bubble up to me. It is extremely hard to keep up with how fast the community it growing, I would love to go over each and every question and continue to contribute, but I suspect the lack of sleep would make me not very productive 
2 Likes
Yes, I sure would. I’ll send you a message. It’s great to hear that you all are already starting to work together on things.
On a related note to the release cycle, is there somewhere in the guides (or on the main pages) that links to the Road to 2.0, future-proofing, etc.? I’m personally aware of all the migrations, but where does a new Ember dev get a heads-up about ~June 12 and how the apps will look differently, even at a high level?
Mainly I would love to know that anyone joining the bandwagon in the next couple months isn’t going to make an app full of views, controllers and dynamic outlets only to hear the official 2.0 unveiling and go “oh snap! I have to rewrite the whole thing”. Like being the poor folks who made any iPhone dock Kickstarters right before the lightning adapter came out.
We use ember since its “sproutcore-2.0-days” for multiple applications in production. In the ember-0.x-days upgrades often required quite some research + refactoring. Since ember-1.0 the situation has been continuously improved and I really like how things go now. It really is a joy to work with Ember - and even more so since eak/ember-cli - thanks to the hard work of @joliss, @rwjblue & @stefan!
We’ve certainly felt upgrade pain — we’ve used Ember since before it was called »Ember«. Also, we’re a 1 person tech team (myself) at a small startup.
However, I like the current rapid pace! I think both the frequency and the magnitude of changes are good. JS changes really fast, it’s important that Ember keeps up (which I think it does thus far).
Also, I think the core team does a good job making upgrades easy! Sure, during 0.x upgrades were excruciating at times. But that’s to be expected with beta releases. So, we’re pleased with how things work and I think the core team does a great job!
(I’m not saying that people who disagree are necessarily wrong, circumstances differ. Only that this hasn’t been a major issue for us since 1.0)
I’m very glad to see the core team has admitted in their meeting that “there are real issues” and that an LTS release is not really a solution. Notes here: core-notes/june-26.md at master · emberjs/core-notes · GitHub . I’m sorry though that they see this as something they should keep in mind for 3.0 rather than considering if they can do anything about the pain we are experiencing now. I’m also sorry there was no mention of my proposals given here: https://github.com/emberjs/rfcs/pull/56#issuecomment-114339423
I hope to once again emphasize that API churn, not a fast release cycle, is the real problem. Lack of documentation in time for a release is a huge, visible symptom of that problem.