Update to latest Ember

[wagenet]

Drops support for older unsupported LTS releases.
Fixes deprecation warning in beta.

[Turbo87]

@wagenet was there a reason for dropping support for these older versions? since many addons depend on caret versions of ember-concurrency and having multiple versions of an addon isn't handled by Ember CLI (yet) having major version bumps here can cause big problems in the ecosystem 🤔

[simonihmig]

I would second that! I find this quite unfortunate, given that many addons that have broader support guarantees depend on ember-concurrency. I am using it in ember-bootstrap, which still supports Ember 2.3+ (soon to be changed though, but only to Ember 2.18+, which all the polyfills for modern Ember features support).

With this change here, I would have to install 0.10 for Ember 3.4+ (to silence the deprecation warning), and 0.9 for the older versions. Which would mean I cannot just keep it in dependencies, but would probably have to add it as part of the default blueprint with some version detection logic. Same would be required for all the other many(!) addons that depend on it and support older Ember versions.

Also wondering

• what the current support matrix actually is? Didn't find it in the documentation, which is unfortunate. And according to the ember-try scenarios that would be Ember 3.4+, which would be a quite radical step IMHO!
• what the motivation for this was? Seems the PR here didn't add any breaking changes at all AFAICT?

Fwiw, this PR updating the dependency to 0.10 did pass in all Ember versions >= 2.3!

[simonihmig]

Following up on this, as this new version de-facto does not introduce breaking changes, I would propose to at least re-establish support for older Ember versions (back to whatever it was before???), by documenting it and adding back the test scenarios (which should still pass I think!), so addons don't run into the problems I described above, and can do the Octane/post-Ember-2.x transition in a calm way.

As we cannot unpublish 0.10, this does not help with the dependency churn issue @Turbo87 was describing I guess...

[machty]

Sorry yall, I probably should have asked more questions before merging this.

@Turbo87 you mentioned this was a major version bump, but 0.9 to 0.10 is only a minor bump, no? Are minor bumps also problematic to the ecosystem?

If all the tests are still passing I don't see any issue in adding back the ember-try scenarios we he had before. @wagenet what do you think?

[simonihmig]

you mentioned this was a major version bump, but 0.9 to 0.10 is only a minor bump

I think what he means is a minor version bump in an unstable package (0.x) has - by convention at least - a similar meaning like a major version bump for a stable package (>1.0), i.e. it signals a breaking change.

Are minor bumps also problematic to the ecosystem

Yes, somewhat, as npm's caret ^ selector behaves differently for unstable versions than it does for stable ones, in that it does not match across different minor (unstable) versions (given that those could contain breaking changes). So if you have three addons, depending on ^0.8.0, ^0.9.0 and ^0.10.0 respectively, you end up with three different versions of that dependency, as npm is not able to find a single version that satifies all of them. And as multiple versions of the same addon are not really supported in Ember CLI, it might get messy...

@Turbo87 sorry for answering on your behalf, but I think that's what you had in mind, right? 😝

[machty]

@simonihmig would you mind putting in a PR to restore things to the ideal? I think I know what to do but if you did it we could avoid some back and forth.

[Turbo87]

@simonihmig exactly what I meant, yes :)

[simonihmig]

would you mind putting in a PR to restore things to the ideal?

@machty sure, can do that!

[simonihmig]

would you mind putting in a PR to restore things to the ideal?

Done: #293!