I personally feel the rush of deprecations in order to hit the Ember 2.0 June 12 deadline has been a larger problem than the six week release cycle in general.
This is my biggest gripe. It’s not that big of a deal but running ember init after upgrading and going line by line to fix ember/ember-cli dependencies in these files.
@domchristie I want to rant and rave my experience upgrading two enterprise apps the last several months.
(1.5/1.6 to 1.9/1.10, ember-rails & ember-cli, rails & php, ember-data & non-ember-data, all views to mostly components, etc). I think I’ve gone through many colors in the crazy Ember upgrade rainbow, and yet I don’t touch the core code so you could call me a “realistic” outsider dev.
First off, I love Ember, love love love, thank you all for everything you do.
I want a bigger Upgrade guides list that’s linked right from the front page on emberjs.com. Whether it’s on the main site or a github page somewhere else, I don’t care, just somewhere it can be updated often.
The release blog posts are wonderful but they’re just the tip of an upgrade iceberg. The rest of my upgrade time is spent on:
- Google (for posts in the last 3 months)
- Stack Overflow (for posts in the last 3 months)
- Checking @ember or @emberwatch on twitter
- Skimming through the audio/video/blogs on Ember Weekly
- Checking the API guides and source code links and switching the Github tag to make sure that’s the current API
- Poking through the dev tools and Ember Inspector for any failed promise or caught exception that isn’t documented
- Re-checking every plugin or addon for compatibility based on Ember 1.X or ember-cli 0.x.xx
- Checking the issues and PRs
- Relying on 2 years of full-time Ember experience, X more years of front-end work and Zen literature to get past anything else
That’s the great thing and bad thing about open source, the answers are free but they might or might not be anywhere or nowhere! It’s mind-boggling to upgrade every time, and I’m lucky enough to know where/how to look for most of it.
I don’t expect the core team to provide a giant 1.9->1.10 page with curated links, threads, addons etc. but the community can. If we could make a big community page like that devoted to a specific upgrade, could we link to it from emberjs.com? So for all the people without the time to do endless research, they have a list where everything’s relevant to their current upgrade? And when people ask how to upgrade, we link to that?
EmberObserver does an awe-inspiring job providing context for addons. I think it would be great to do something similar for getting people over each version hump where every link is “version 1.10 approved”.
I’ll make the damn Github pages if people can help send me links to stuff.
Also at the top of every addon’s Github readme, they could put “we expect this to work with Ember 1.9+ and ember-cli 0.18-0.2”, then the first thing we all see is if we can use it with our current app’s versions.
TL;DR I <3 Ember, but I want a curated Github page devoted to specific version changes. I’ll take the lead if no one else wants to, but I’m tired of cross-checking the whole Internet with a calendar to find answers.
3 Likes
Just want to drop in and say that I’ve been bitten multiple times with the Ember upgrades. Usually this is my fault, 
but trying to refactor a large Ember app has been becoming increasingly difficult with the massive number of changes and deprecations. (ie. I still have a ton of controllers in my app, and I wrote code expecting the store to be injected into controllers, which doesn’t work all the time, so I end up looking it up via the container in the meantime while I try to move my data fetching logic to objects that get interacted with by the router).
I’m not against the 6-week release cycle per-se, but having the core team say something to the effect that it’s a developer’s responsibility to report back bugs to the framework seems a bit out of touch with the reality of how some organizations work. Sometimes there isn’t enough time to report the bugs and instead we’re forced to roll back a version in hopes that a later version will fix our problems because there isn’t enough money, time, nor staff to handle all of the work required for the app.
FYI, this is just how I personally feel sometimes. Talking to Stef and other devs in person has been extremely informative and helpful, and I have never felt chastised or unwelcome 
As a newcomer to Ember this is a must. The first thing you see is “npm install -g ember-cli”. When you go to the guides section it shows info for 1.10.0, this is confusing.
There are a few ways to solve this but the simplest would be to remove the commands from the homepage, add a single button that links to the builds page. Add an ember-cli explanation and commands there. Perhaps a sentence and link pointing them to ember-cli.com too.
It would be a lot of work but if we want to continue the adoption of ember-cli there should be a question that asks what build you would like after the ember new my-app command is entered.
1 Like
Yes. I also didn’t mean to call out a low number of issues, but issues/twitter/so are the only mediums by which I can aggregate information and pains from your users.
I think this also boils down to the fact that so isn’t really maintained or curated like it should be. Especially for the I am having trouble with x but don’t know what is the problem.
I have honestly been quite apprehensive of diving heavily into so, but maybe that is part of the missing piece.
My and likely the rest of the communties goal is to improve productivity and minimize waste. Honestly people’s pain is waste for me, as I must triage issues. If we can keep pain to a minimum,energy spent on issue triage lowers and we can focus on better things.
All we must figure out is how to improve this feedback loop, catch pains early and try and make them disappear entirely.
Another thing I was thinking was to have bi weekly ember town halls in Google hangouts on-air. Something where we can us Google moderator to bubble up some commons points and get some nice high bandwidth discussion
3 Likes
I feel like the most we could reasonably ask for SO issues is to tag the heck out of posts (ember 1.9, rails, ember-data, etc.) so we can search by that instead of just by text. Even if the posts can’t all get curated or maintained, just being pokey at people to tag as much as possible could help. I know Twitter doesn’t have the same room for a question and 5 hashtags, but maybe it could help out on IRC too.
The town hall is a cool idea (especially having a blog post of the minutes after it’s done). You and every other big contributor has the (hardest) job of answering questions wherever they show up, and anything to reduce the places you need to look for questions, the better for us.
I’m serious about wanting to make upgrade-related community pages to help collect all those awesome answers, so we don’t always have to look in 13 places for them, and hopefully save the core team a ton of duplicate questions.
I know personally that with almost every Ember-related bug I have, I assume it’s my fault and after enough scouring the Internet I find the answer. It’s awesome how rare I hit a real, unresolved issue that hasn’t been reported, and that I can’t work around with a few more lines of app code while it gets resolved. Even when I’ve been on beta and canary. So I’ve loved the fast upgrade cycle. I think the versioned guides, more tagging and easier community searching will help everyone who hasn’t been following along the whole time.
I’d like to do a quick chime in to support the 6 week cycle. Each upgrade has been pretty painless for me, taking no more than 30 minutes each time. And even then, if I miss one or two of these releases I don’t feel like I’m THAT much behind the curve of the community.
1 Like
I am unsure how we are supposed to fix bugs we don’t know about…
1 Like
I think what I’m trying to communicate is that when I report bugs, it seems like a test case is always needed for it to be actionable. Which is reasonable. However, it has relatively high barrier to entry, since the test suite internal to ember is a different beast than what is presented to app developers, especially when the issue is related to the intersection of multiple features (cf. the ember-routing-named-substates issue I’m working through with you).
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
2 Likes
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.
2 Likes
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:
- 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 returnsapp/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.
Addons
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.
15 Likes
Yes. I would consider any private API needed for a plugin as a bug. Please file 'em!
1 Like
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. 