Is the six-week release cycle too frequent?

Proposals
62

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:

Paraphrased:

  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

5 Likes
63

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.

2 Likes
64

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.

65

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.

1 Like
66

@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.

67

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.

5 Likes
68

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

69

@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.

70

@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.

6 Likes
71

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.

2 Likes
72

Yes, yes, yesssssss, to all these points.

One thing that might push this forward is good reference examples of how “ecosystem stewardship” is done well. A polished, opinionated, guide or two from the core team that demonstrate how to structure add ons or build bullet proof external dependencies would be awesome and likely serve the community well.

Speaking from personal experience one of the things I had difficulty with when trying to poke at Ember internals is understanding how it all comes together. Ember itself is actually composed of various micro libraries. As an outsider it is sometimes hard to connect all the dots and see how the pieces actually fit together nevermind understanding best practices on how to package or prepare something for NPM and or bower. And forget about troubleshooting other dependency breakage if you understand nothing about how it is “suppose to work”.

Who, What, How and Why of good ecosystem stewardship.

Speaking of Node and NPM… a side comment about Ember JS website.

Home page used to have easy to download starter kit. Which has now been replaced by short note on how to install ember cli and gen new app.

I believe this should be accompanied by some introductory guide that discusses node, npm, node_modules and the node ecosystem in general terms and how ember cli works within this system.

IMHO novices who have no context for node, npm etc will have a hard time with this.

At various meetups and training sessions that I have helped on, invariably there is need to help folks learn to fix and or bootstrap their local node and npm dev environment.

Ember CLI docs do a reasonable job but a more prominent “here is the ecosystem and here is how it works” will go a long way helping new comers and the less experienced.

And long term I believe Ember CLI will be a great force for good in taming the node ecosystem.

@stefan it is quite breath taking to see how far Ember CLI has come especially from the Ember App Kit days. Very well done sir! Quite an amazing job. It feels like a lifetime ago when I was a total nodejs noob first bitching on your personal git repo about node and sudo commands.

:smile:

While there is still a long way to go new comers might not fully appreciate how far things have actually come in a relatively short time.

1 Like
73

Ya, we are planning to have this in-place by the 1.0 release of ember-cli. This area is still in flux, although we are spiraling in on sanity. Although I am not apposed to something like this existing today, when triaging time it is hard for me to write docs.

Maybe a way to kill 2 birds with one stone is to write something up, that describes where we want to go and annotate what is completed and what is still pending. So basically, a hybrid guide/rfc/milestone doc…

ya agreed, would love to have help here if you are able. I can gladly help audit and curate

points that need love

  • don’t install npm with sudo
  • using a modern version of npm and node (npm v1.x is basically broken)
  • etc.

thanks, when looking at what we have and where we still need to go, it seems extremely daunting. But looking back, and seeing how far we as a community have come, really makes our next set of goals seem totally possible.

I am also extremely surprised how many people survived those days, and can now benefit from the collective contributions and effort to escape that dark and scary time.

Looking forward to more great collaborations!

74

I think this is a good strategy. A skeleton outline or todo list git issue can go a long way in helping point the direction and help motivate others like myself who would like to help but don’t always know where to start.

I will see if I can take a crack at initial intro to node guide and post it somewhere for review. I have had to reinstall entire node environment at least half a dozen times already. :smile:

1 Like
75

ya… keep me posted. I’ll help provide feedback.

It doesn’t help that the nodejs.com installer installs stuff with sudo… /me facepalm

76

@stefan here is a WIP for an introduction to Ember CLI, NPM and Node guide.

Still probably more to add. Welcome feedback on additional topics and outline. Once I firm up I can submit PR to website guides. Some of this is probably duplicated elsewhere but I think we should definitely have something front and center for folks brand new to Ember CLI and Node.

3 Likes
77

awesome, i’ll provide feedback when in PR form. Gists don’t have the nice inline comments.

78

This thread seems to have evolved in to “what more can we add to alleviate upgrade issues?”, and I don’t think adding more will necessarily help. More guides, curated upgrade pages, version-tagged Stack Overflow questions, and Google Hangouts, will add more layers of documentation, and more components to maintain.

It’s a cliché, but I’m actually advocating doing less, to help reduce the seemingly never-ending stream of changes. These changes are covered by the SemVer promise, but they still exist, and encourage developers to adapt (or implement upgrade policies) which can be unproductive.

It’s reassuring to hear from Ember Core team members, and that releases may slow down when the ecosystem stabilises. I have been using Ember for three years now, and it can often feel like the next big thing is just round the corner. So as to when things will stabilise, I guess only time will tell.

79

Ha! We definitely need a “Betteridge Headline” Discourse Badge!

1 Like
80

This reminds me of a previous life as a .net developer around 2008 reading on msdn forums and ScottGu’s blog ppl begging “Microsoft please slow down, we cant keep up”. While other devs where thinking, come on Microsoft you need to keep up with Rails, et al.

2 Likes
81

@stefan, we are looking for something similar tomrun our test suites. The solution is hacky, but Im thinking that with a but if work it could become a nice addon. I want to run different Jenkins jobs against beta and canary to at least make sure we are not making things worst and we can fix ember issues early on.