[BUGFIX release] Ensure that Component context is not forced to parent context.

[rwjblue]

Fixes #10401.

[rwjblue]

/cc @ebryn @mmun

[danfinlay]

For previous versions of Ember, what is the solution to running into this bug? I have a component template (Ember 1.9.1) that tries to render with its parent context, and this isn't the first time.

[rwjblue]

I think the solution for 1.9 is to either monkey patch (not recommended) or upgrade.

[danfinlay]

It would be great if fixes like this were merged into all the minor versions for the next release cycle, so everyone could have the benefit of bug fixes without the full pain of migration.

[stefanpenner]

It would be great if fixes like this were merged into all the minor versions for the next release cycle, so everyone could have the benefit of bug fixes without the full pain of migration.

wanna submit a PR doing this?

[danfinlay]

I would gladly. What branch would I PR this to, or would I just make a new branch? Not sure how old versions are supported.

[rwjblue]

It would be great if fixes like this were merged into all the minor versions for the next release cycle

• The issue that this PR fixes we reportedly working properly on 1.9 (and broken in 1.10). The fix was incorporated into the versions that the issue was reported against.
• Every commit on master that isn't adding a feature or just a simple refactor (these two are fairly rare) are ultimately fixing something. We can't do a patch release for every commit...

so everyone could have the benefit of bug fixes without the full pain of migration.

We strive to make the pain of upgrading as small as possible, but I realize that there have been a few doozies lately. Sorry about that.

[stefanpenner]

@rwjblue should we maintain branches for past releases that auto-build commits? Might be nice for this interim fixes, then when a sufficient number of them have occured we may decide to cut a release?

I suspect this may be hard due to changes in build tooling, but maybe something worth exploring moving forward? Especially with the LTS pattern we plan.

[danfinlay]

Every commit on master that isn't adding a feature or just a simple refactor (these two are fairly rare) are ultimately fixing something. We can't do a patch release for every commit...

Of course not. But if you were following the semver versioning scheme, (which I think Ember does), you could just keep an open branch for each minor release, that bug fixes are merged into. You could keep the same 6-week release cycle, where you mark the current master branch as a "release", and every minor branch could stay as stable as possible.

If this sounds like too much work (a long history of minor releases), you could limit the support merges to a subset of the most recent minor versions, ideally with occasional "Long Term Support" versions, that are also cared for, probably versions before particularly painful migrations.

I wonder if there is data on what versions are being used the most. (Does github or bower provide this?) I'd really like to see if there are particular versions of Ember that people are choosing to not migrate from because there are so many breaking API changes.

In the very longest term, I dream of a world where API isn't broken without an ember-watson companion conversion script.

[danfinlay]

Oh haha, I didn't see your post while I was writing, @stefanpenner. I'm glad to hear there are plans for some LTS system. Any word on how the LTS version would be picked?

[danfinlay]

should we maintain branches for past releases that auto-build commits?

I hadn't even considered automating the minor release patching, but that would be really cool!

[rwjblue]

To reiterate what I said above:

The issue that this PR fixes we reportedly working properly on 1.9 (and broken in 1.10). The fix was incorporated into the versions that the issue was reported against.

Even in a world where all reported bugs for all versions going back forever are fixed, this would not have been backported to 1.9 (because it was never reported as a bug in 1.9)!

[danfinlay]

Hi, I'm on 1.9.1, and I've been frequently getting the parent context within components. Is there a way I can check to see if this is the same bug?

Also, I think the broader discussion I awesome and I hope in the future either LTS or ember-watson is heavily supported.

[stefanpenner]

@FlySwatter some further thoughts on LTS https://github.com/emberjs/rfcs/blob/two-dot-x-improvements/active/0000-improved-release-cycle.md

[danfinlay]

Great read, @stefanpenner. Excited that LTS is in discussion, and it's also really valuable to know that deprecation warnings for private APIs are only guaranteed a single patch release before. It seems like the easiest upgrade path right now may be to go one minor patch at a time, and upgrade after all deprecation warnings are fixed.