4 ms·

It sounds like the core team is contemplating doing LTS releases, which should ease the fears of anyone who worries they'll be left behind if they can't keep up

It sounds like the core team is contemplating doing LTS releases, which should ease the fears of anyone who worries they'll be left behind if they can't keep up. source: https://github.com/emberjs/rfcs/pull/84#issuecomment-130451156 https://github.com/emberjs/rfcs/pull/84#issuecomment-1304511...

tsmarsh 11y ago
I'm not sure LTS would help us. If 1.8 had been deemed LTS we may have delayed the upgrade work until it was EOL... then what? We'd still be facing months of upgrade work, but on a significantly larger code base. This is a problem of platform maturity. The Web is moving too quickly for monolithic framework solutions to keep up. ES6, web components, shadow dom etc were not part of the landscape 12 months ago. Ember and Angular are both doing admirable work in all of these spaces, but they're leaving their users in their wake. I'm just not sure what you are supposed to do if you want to build a multi-year project with modern frameworks in 2015. My current suggestion is that we don't, accepting that the web site is just a skin over your api, that needs to move with the fashion, so expect to replace it every 12 months, minimum... that doesn't go over very well with executives.
- phren0logy 11y ago
  Sure, but does doing it all by yourself really put you that much further ahead? That does not slow the pace of change. You have more granular choices, but you have many many choices you are forced to make. If you trust the people making decisions behind the framework, it still seems like the better choice.
- wldcordeiro 11y ago
  The solution would be to do the incremental updates as they were released. Yeah it's no use to you now after you've fallen behind but it's the easiest way to be able to update your project rather than dropping behind 4-5 versions.
- mixonic 11y ago
  > they're leaving their users in their wake. The jump to Ember.js 2.0 involves API changes, but I see no reason why the majority of application will not move forward. Your experience sounds very painful, but many Ember applications, even ones that are over two years old, have already made it onto 2.0. That is not meant to trivialize your pains, but just to challenge the idea that we're leaving people behind. Ember's 2.0 strategy is specifically designed to ensure as many people get to 2.x as possible. That is our goal. I'm rather proud of the number of mature, long-living codebases build with Ember that continue to progress with us. > I'm just not sure what you are supposed to do if you want to build a multi-year project with modern frameworks in 2015. My current suggestion is that we don't That is an option. The web, and single-page applications, offer unique advantages but like any platform also come with limitations. Companies like Yahoo, LinkedIn, Zendesk, Twitch, Bustle, and many others have placed big bets on this architecture though, and use it successfully.

tsmarsh 11y ago

I'm not sure LTS would help us. If 1.8 had been deemed LTS we may have delayed the upgrade work until it was EOL... then what? We'd still be facing months of upgrade work, but on a significantly larger code base. This is a problem of platform maturity. The Web is moving too quickly for monolithic framework solutions to keep up. ES6, web components, shadow dom etc were not part of the landscape 12 months ago. Ember and Angular are both doing admirable work in all of these spaces, but they're leaving their users in their wake. I'm just not sure what you are supposed to do if you want to build a multi-year project with modern frameworks in 2015. My current suggestion is that we don't, accepting that the web site is just a skin over your api, that needs to move with the fashion, so expect to replace it every 12 months, minimum... that doesn't go over very well with executives.

phren0logy 11y ago
Sure, but does doing it all by yourself really put you that much further ahead? That does not slow the pace of change. You have more granular choices, but you have many many choices you are forced to make. If you trust the people making decisions behind the framework, it still seems like the better choice.
wldcordeiro 11y ago
The solution would be to do the incremental updates as they were released. Yeah it's no use to you now after you've fallen behind but it's the easiest way to be able to update your project rather than dropping behind 4-5 versions.
mixonic 11y ago
> they're leaving their users in their wake. The jump to Ember.js 2.0 involves API changes, but I see no reason why the majority of application will not move forward. Your experience sounds very painful, but many Ember applications, even ones that are over two years old, have already made it onto 2.0. That is not meant to trivialize your pains, but just to challenge the idea that we're leaving people behind. Ember's 2.0 strategy is specifically designed to ensure as many people get to 2.x as possible. That is our goal. I'm rather proud of the number of mature, long-living codebases build with Ember that continue to progress with us. > I'm just not sure what you are supposed to do if you want to build a multi-year project with modern frameworks in 2015. My current suggestion is that we don't That is an option. The web, and single-page applications, offer unique advantages but like any platform also come with limitations. Companies like Yahoo, LinkedIn, Zendesk, Twitch, Bustle, and many others have placed big bets on this architecture though, and use it successfully.