Ember table shim should be automated on release

[danjamin]

I have created a shim for ember table ember-table-shim which is a temporary place for it. This allows developers to install just the needed files through bower to get up and running instead of the entire project.

What should probably happen, is it should become part of the Components organization.

For now, it is easy enough to build and copy the files into the shim and tag the release.

However, this should become automated using something like grunt-release-component.

Then, it is simply a matter of changing ownership of the shim repo.

[djtcin]

+1

[lucaspottersky]

+1

[petrvolny]

+1

[in2lag]

+1

[azirbel]

Made a PR for this - feedback is very much appreciated. #148

[azirbel]

Hey everyone - looking for some extra feedback. I got pretty excited about the idea of getting the dist folder out of version control, and got as far as setting up a one-step release process in the PR I've linked. I'm about ready to merge it and switch bower to point to a new shim repository, but before I do I want to make sure that this is really a good idea.

It's easier than before to make a PR, since you no longer have to add dist files, and the reviewer doesn't have to check that they are correct - so that's great. It's still easy to develop ember-table locally and test against your app, using "bower link".

But it's now very inconvenient to maintain a forked version of ember-table, or to make a critical bugfix on your fork/branch and link your production app against it. New code won't be available until we release a new patch version, or unless you temporarily put the dist folder back into git. Is that ok, or will it frustrate ember-table users? I'd like to hear your opinions.

@yayalice and @bigsley might have opinons as well.

[azirbel]

Another update - I merged in the bower/versioning work (#157), but left out the shim repo for now. It's easy to add back once we're sure it's a good idea.

I'm still interested to hear arguments for/against using a shim repo. Bower shouldn't be copying in the entire ember-table repo, because we've set a list of ignored files in bower.json - so I don't think there's an advantage from bower copying in just the needed files.

The main advantage I see is moving distribution files out of version control, which is pretty great. However, having a shim repo adds some complexity, and makes it harder to maintain a forked repo or bugfix, as I mentioned above.

Other thoughts?

[jrhe]

I don't think its worth the complexity.

Bower still has to download the whole git repo but that only happens once so its not so bad.

What are the main arguments for moving dist files out of version control? Yeah you have to make sure its built before doing a release but other than that. Is building part of doing a release? I think if people want bleeding edge they can build for themselves and otherwise building is part of releasing so dist only gets updated for releases.

[billy-addepar]

This version of Ember table is no longer supported. If you want to continue discussion, you can open the issue on Ember Table Legacy