Kick off 2.0-beta

[mixonic]

Per Addepar/ember-table#819 we're pursuing a 3.0 release for ember-table which drops IE11 support and Ember pre-2.8. As ember-table is likely the most active contributor of this library, I would also like to release a 2.0 of vertical collection dropping support for IE11 and Ember < 2.8.

This branch should kick that off.

[mixonic]

Annoyingly although ember-table supports back to Ember 2.4 (back to 1.11 on master!) this library is only tested in Ember 3.x and does not pass on 2.x.

[RobbieTheWagner]

This seems fine so far. If we're dropping IE11, maybe we should also drop Ember 2.x?

[mixonic]

Addepar relies on 2.x support both for ember-table and various internal component implementations. Ember-table itself is probably the single largest consumer of this library, and since we can't drop Ember 2.x from ember-table yet we should not drop it from here. In fact I would like to add it to the test suite.

Quickly brainstorming, the advantage to dropping 2.x afaict would be a more stable component manager API which may allow an implementation here to operate at a lower level, or at least at a low level on a stable, public API instead of intimate API. But we could probably also use those APIs progressively during a vertical-collection 2.x cycle and drop weight at 3.x.

[apellerano-pw]

Is there any plans to integrate the horizontal-collection / virtual-collection pattern proposed in #269 into the next major release?

[knownasilya]

I'd love to at least get an Ember 3 and IE11 release, since Ember still supports IE11.

[RobbieTheWagner]

I don't really know much about the internals of this repo, but happy to add anyone as maintainers if they want to help get this over the finish line!

[mixonic]

In alignment with a proposal at Addepar/ember-table#819 (comment), I've opened a PR at #325 moving the minimum supported version of Ember for the 2.0 branch to 2.8.

[mixonic]

@twokul and I discussed and we think the last item here is the ember-raf-scheduler dependency getting a bump.

[twokul]

As per discussion, #328. I believe after it is merged, we can safely merge this PR and proceed with the release of 2.0.

[RobbieTheWagner]

Should we label this as a beta?

[mixonic]

This format of version number is commonly used by NPM packages to identify a pre-release. The published package on NPM is tagged next, which is basically equivalent to beta (only the latest tag on npm is for stable packages).

You prefer the -beta style versioning? Or were you referring to the npm tag?

[RobbieTheWagner]

I'm just used to seeing -beta on betas.

[mixonic]

I've integrated this into ember-table and into a large codebase. I think we're good to land it and cut 2.0!