Is the six-week release cycle too frequent?

Proposals
21

I think you mis-understand, I do not maintain, rather other employees at yahoo do. My involvement is merely to review to ensure upgrades happened correctly, collect feedback (re: pains), help investigate bugs and pain points. Using this information, I then attempt to fix the root cause of the pain in ember/ember-cli. This I believe does provide me with the realistic gauge you suggest I may lack.

Upgrades track closely with upstream (releasing in lock step) are usually without pain, when pain points arise, I use that feedback to:

  1. update the change-log
  2. attempt to mitigate the pain all-together by fixing some issue

pains that have bubbled up seem to boil down to:

  1. npm installed incorrectly (as sudo, or multiple different installations polluting each other)
  2. npm cache corrupted
  3. bower’s choose your own adventure resolution strategy
  4. package.json merge’s from ember init that require to much context
  5. bower.json merge’s from ember init that require to much context
  6. ember-cli ↔ addon inter-dependencies
  7. ember-data’s changes
  8. using ember.js private API’s

The majority of ^^ have active efforts that as we evolve, will eventually vanish. They key part here is, we must evolve to address this issues. Not evolving keeps these issues around for-ever. Unfortunately, sometimes the best way to address these issues is to change how we approach a-problem.

For those migrators who review the short and concise change logs we curate (like Release The Addons Nest · ember-cli/ember-cli · GitHub), typically few things cause issues. But ultimately stuff can, when issue arise we rely on feedback to fix and mitigate the pains. Luckily my feedback-cycle is a relatively large pool of devs at yahoo, and the wider community who report issues.

To help improve this feedback loop, please provide issues as you encounter a pain point.

a quick search across github suggest you may not utilizing this medium to report upgrade pains:

@domchristie thank you for opening this discussion, my take-away is that more feedback on pain-points early enough in the cycle is what will enable us to mitigate incremental growing pains. Help us by testing, and providing this feedback.

One great example of a rather annoying upgrade, was moving to the new qunit syntax. This was identified as a pain, and as such @abuiles wrote an excellent migration tool GitHub - abuiles/ember-watson: An Ember.js codemod to make upgrades automatic. that mitigated the pain nearly entirely.

This was only the result of a good feedback loop and an active community keen on mitigating their own and others pain.

2 Likes
22

I believe you have identified the pains we all feel in client side development. The goal of the ember project is to continue to reduce complexity and improve over-all productivity. The hard-part is, the starting point is essentially the wild west. It takes several iterations to derive those stable primitives, and once they are derived. We quickly forget the pain we originally had, and the next pain-point overwhelms our senses.

For some the evolution itself is the pain, I think we can strive to continue to reduce those growing pains. One thing worth noting, is that the evolution is nearly always motivated/justified by some even larger pain. Maybe we do a poor job, messaging the trade-offs?

I do believe with more community feedback and help, we can continue to pave an even nicer evolutionary path.

23

With 6 week releases (for ember), and shorter for ember-cli (for now) their is a good flow to rolling out improvements.

imagine if we released every 6 months, this individual would need to actually wait months not days for a fix.

24

Yeah as mentioned I have not mentioned this as I am aware it isn’t stable, my point which I didn’t really make clearly was the ‘long term support’ idea has been in the back of my mind because of this.

25

My only issue around this is security updates would need to be back ported for a period of time somehow.

26

I’m not sure that is fair or productive comments like this, let me further explain my recent transition to Ember.

LTS gives backported security updates which to my knowledge isn’t always available in Ember core.

My other point is core packages are maintained outside of Ember which could break functionality by fixing security updates for example. My LTS idea would be similar to how Ubuntu behaves in that they update packages / fix them if they are part of the core and are important for security/bugs.

I wasn’t complaining either. I was stating the pain points I have had and the idea that has been present whilst fixing these issues that have arisen. I am aware I have been using two beta products however from all that I have seen and as @domchristie has hinted that a move to ember-cli will happen soon (even the Ember site points you to it on the home page). After all Node has not hit version 1.0 yet but is relied upon in production builds; with usage becomes some form of stabilty however careful the developers are of not branding themselves as done.

What has felt urgent as part of building an app is to use Ember data and ember-cli to maintain long term stability. The only way I can see enterprise picking Ember up would be with good build tools like EAK or ember-cli. With so much moving in the core towards these packages, it has felt impossible to create a new app without them unless I was given the time for a fairly substantial rewrite around June.

I have actively stayed away from using large front end frameworks until they felt stable enough and I am glad now that Ember is getting there. I have written four separate different SPA frameworks now going back as far as 2008 for companies I have worked for and yet despite the pain, the stability of using ember-cli and Ember data has been far less stress and easier to train other developers in.

27

We take security issues very seriously, and always backport to affected versions if at all possible.

2 Likes
28

Absolutely! I was not aware of your role, so thanks for clarifying (and apologies if I caused offence with the comment—it was not intended!)

I feel it’s a little unfair to highlight my low issue numbers, as it doesn’t show the number of times I have searched through issues or stack overflow answers, or implemented temporary solutions (e.g. Upgrading to Ember-CLI 0.2.0 · GitHub). As I have mentioned, I have often found solutions on these sites, in which case there is no need to raise an issue (+1s can just be noise). I have also mentioned that it’s sometimes hard to know what part of the stack is at fault: ember-cli, ember, ember-data, or me!? As your screenshot indicates sometimes it’s really hard to describe or search for an issue, or create a breaking example. Just like conversion flows, it only takes difficulty in one step for a user to abandon (or in this case a feedback report to be lost). If you want more feedback and don’t mind dupes/+1s, perhaps this should be included in the contributing guidelines?

Whilst I’m not prolific, I do try and contribute feedback, blog posts, and answers when I can (though I could probably do better on the feedback-front). FWIW I found this Stack Overflow answer from 2012, mentioning the Ember.ObjectController hokey-cokey. Topical!

Anyway, I appreciate your responses (and your work in general!), and glad that this topic has been of some use.

29

Good to hear, I wasn’t sure if this was the case. My only other worry was with third party issues for example if jQuery needed an urgent change that wasn’t backported in older versions of Ember. For serious issues I have seen Linux distros make a temporary port to prevent the world from falling apart by upgrading to the latest package. I’m not sure if this has happened so far within the core of Ember however I’m fairly confident that from the good work you are doing within ember-cli this has happened there and you have ported the packages or found a work around.

30

I also agree that there should be two release channel i.e. fast paced and LTS. As a Tech Lead working in Enterprise, we always look for stable things. For example, if you look Symfony2 PHP framework, they have LTS version of 3 year and normal version for 6-8 months. This gives an enterprise opportunity to invest there resources for bigger projects. IT Architect never approve if the things are not stable enough.

I would appreciate how Ember community is working very hard to keep fast pace and frequent release cycle. But it would be better to mark one version as LTS for at-least a year i.e. you can mark Ember 2.0 as LTS, keep releasing 2.1, 2.2 etc. while small/stability fixes for 2.0 as 2.0.1, 2.0.2. After 9 months, you will reach for example 2.7 which would again Ember 2.7 LTS. Rest of 3 months you can provide stability fixes for older LTS i.e. 2.0.4, 2.0.5 and meanwhile developers will upgrade to new LTS. This will keep the pace and things better on developers side.

31

Just to put in my two cents: I find, in general, the short release cycles make upgrading relatively pain-free for someone like me spending the majority of my dev time in Ember. BUT, my coworker is primarily a back-end (Rails) dev, who has recently been trying to get up to speed on the Ember side of our app. Let’s just say “I’ve had a lot of explaining to do”…things like is this the Ember version, or the Ember Data version, or the Ember CLI version…or should I use ember install, bower install, or npm install…etc. become painfully obvious.

Now, I totally understand that this is not Ember’s fault per se, and that much of the work on Ember/EmberCLI is trying to resolve these pain points, but do want to emphasize that they are MAJOR pain points in that they discourage devs from even getting over the initial hurdle of digesting a full-fledged Ember app. I do concur that much of this is related to the pains you’ve pointed out already. And as @domchristie, pointed out many times opening an issue is not the answer as a pain point is not necessarily equivalent to a problem with the codebase, but rather a lack of understanding all the moving parts at play in an Ember CLI-based app (opening an issue seems rather heavy handed for something that can usually be mitigated by a Google/SO search).

Anyways, all that being said, I’m super grateful for all the work that’s being done to accomplish the goals of Ember/Ember CLI, and having gotten over the initial speedbumps, I can say that the productivity gains are well worth it. Looking forward to development “happy path” with a bright future. Keep up the good work! :smile:

1 Like
32

I actually LOVE the 6 week release cycle. Here’s why!

  • When you’re working with Ember it’s super easy to get all the latest features
  • Small iterative updates mean that you don’t end up doing the big rewrite, for example Rails 3 => 4 was a huge amount of pain, all paid in one go. So six week releases means that you get to pay the price over a long period of time, in small chunks. Additionally, when the major release happens, you’re already comfortable with idioms. Anyone remember switching from attr_accessible to strong params???
  • Each point release is generally trivial to migrate when you go through the process regularly
  • I’ve found very few point releases that have taken more than a few hours to deal with and the docs and release notes are amazing!

The biggest pain point that I see is writing idiomatic Ember. If you’re not writing idiomatic Ember, that’s when you really feel the pain. Idiomatic Ember is a huge learning curve, but at the end I’m convinced that it makes you a better JavaScript developer period.

For those coming to Ember from unstructured JS (think jQuery spaghetti), this is a big deal. You’re learning something new and that is painful, but few things worth know are trivial to learn.

The core team do an amazing job of keeping the community up to date on what’s happening and I’ve never seen another project where the planned major release (2.0) will only be deprecations! All of the new features will have been delivered way before then.

Honestly, if you don’t LIKE the 6 week release cycle, stick on a point release and don’t upgrade. It’s not compulsory.

4 Likes
33

^^

I have yet to see a compelling argument against this. People are mixing other kinds of pains in here and muddying the discussion. Maybe people want the Ember CLI release cycle slowed down? Unlikely to happen before 1.0, I suspect, but that would belong in another thread regardless.

I think Betteridge’s Law of Headlines applies here.

As for enterprise and LTS, this is mostly a labour of love. If enterprise-y corporations need that kind of thing, they should use their massive cash flow to make it happen. It’s working well enough for me without putting that additional maintenance overhead on the already ultra-busy core team. Corporations exploiting open source for profit and giving nothing back but demands is :angry:

:heart::heart::heart: to everyone who’s been working to make Ember excellent.

2 Likes
34

I think we should keep it. I’ve only been in the Ember community since early January, but since that time I’ve already upgraded my app twice. Both were incredibly painless, stable and added features. If there were any deprications, they were enough to handle in a very, very small amount of time in a single sprint. That’s HUGE for agile teams that can’t warrant a whole sprint or more just to rewrite their app for a framework upgrade with no new features. The fast release cycles, assuming they stay small, and stable like they are, are the best way forward currently IMHO.

1 Like
35

Oof, I was going to try to address all points I disagreed with but then I noticed how big this thread is.

In sum:

Agreed.

Agreed.

I think currently a big problem is that while Ember itself has been as stable as possible since the 1.0.0 release, everything around it has been in flux trying to find the best way to solve their problems. Ember Data saw a complete (much needed and improved) overhaul, Ember CLI is still finding its ground, the Guides are getting versioned and updated to Ember CLI, etc.

I think as June 12 approaches and all of the projects start aligning more that this becomes less of a problem. You can’t develop an ambitious framework out in the public and not change some amount of churn.

36

re: maintaining addons

I maintain several popular addons and I have to agree that the 6 week cycle feels aggressive. Add to that the more frequent release cycle of ember-cli and this has created a very frustrating experience for me as an addon developer. Typically the API surface that the core team is concerned with is aimed at application developers, addon developers typically are hooking into endpoints that tend to disappear from release to release. (semi-private) It would be nice if addon developers could get the “stability without stagnation” benefit that application developers get. I have seen no intent to provide such support.

2 Likes
37

Ember CLI 1.0 is also scheduled for June 12. And with that comes the SemVer guarantee that at most the current (as of the stable release) API might be deprecated.
And if the other projects are any indication, Ember CLI 2.0 will take a while :stuck_out_tongue:.

38

@locks that line was referring to supporting an API layer that addon developers can rely upon in Ember itself

1 Like
39

Like all things Open Source the surest way to ensure something happens is to participate materially in the doing.

A LTS branch of Ember sounds like a great idea. I don’t think the core team/community has additional energy to handle the work around this right now. There are several ways to remedy this:

Option 1: JFDI!

The joy of open source is that the source is free for everyone. Starting an ember-lts project where you cherry pick commits into an LTS branch and collaborate with other people who need LTS this is an excellent way to participate in the larger Ember eco-system. It would be awesome if opting into LTS was as easy as pointing to a new repo where additional point release versions existed.

Option 2: Work to get LTS part of the project’s main release process:

Write an RFC for how you would propose a LTS branch would work. Make it a good RFC with lots of data and sufficient research that shows how an LTS process would work in painfully exact detail. One way to make this option a sure win is to do option 1 first and work through all the rough patches before trying to merge it into the existing project. Many parts of Ember that are getting “official” support started with way: list-view, ember-cli, ember-data, etc.

A light-touch (to core) LTS process of “the LTS group has handled everything from collection PRs, cherry-picking commits, testing in wide range of environments, writing release notes and all core has to do is merge one PR” is a pretty easy :thumbsup: to make.

Option 3: Cash Money

If you’re part of the Enterprise world, I assume this means you also have significantly more cash flow than a community-run project. Plus, using open source shaves a good amount off the bottom line in terms of software license you don’t need to buy. Reallocate part of these savings to hire someone on core or in the community to do this work on your behalf.

3 Likes
40

Semantic versioning has been maintained though, right? Your Ember 1.0 app will still work in 1.10.

Man I wish. Switching the Handlebars compiler was a pain, especially with dependencies that were built with older Handlebars versions are slow to get updated. We’ve suffered plenty of small breakages when updating versions.