Do not use bower for managing ember versions about ember-cli

[rwjblue]

In general I am OK with using the updater to just keep the local copy up to date, but if possible, I would like to fix the issues with Bower.

@joefiorini - Is the primary issue you have faced using non-tagged canary/beta builds (based on commits to those respective branches)? Or is there another issue that I'm not aware of...

[stefanpenner]

But other deps might depend on ember, with version deps..

[joefiorini]

My main problem is when I need to go to a non-release channel my only option is to get it from S3, which changes the name of the file to index.js instead of ember.js. It also means that I can't take advantage of bower's versioning, because bower doesn't know about versions that aren't git tags. Although, I just realized that we tag beta releases, so I guess this is only an issue on canary, right?

[joefiorini]

It's starting to feel like we're conflicting with bower's functionality. If we keep ember in bower, then the updater should just interact with bower. If we want the updater to directly download ember/ember-data versions then we should take ember out of bower altogether, right?

@stefanpenner if other deps depend on ember, then the user will never want us to automatically update ember, right? Seems like it would be bad to prompt people for updates if it could conflict with their bower setup. I'm starting to think we should only enable evergreen if they aren't using bower for ember. This can be by either a) using bower by default and allowing them to opt out if they want evergreen or b) not using bower by default (just for Ember/Ember-Data) and turning off evergreen if bower.json contains ember as a dependency. I'm not sure how to handle libs that depend on ember themselves. Open to other thoughts.

[rwjblue]

I'm pretty sure that I can get the per-commit builds pushed to the bower repo. Then you can use either tags, or branches (for canary/beta/release). This should make it possible to keep the Ember version evergreen'ed (via bower though), but it doesn't solve the issue of dependencies requiring different versions.

[joefiorini]

Talked with @rjackson about this on IRC yesterday. We agreed it makes sense to just let bower do the updates. He's working to get each channel in its own branch, which should ease our checking for updates. So "subscribing" would likely be just updating bower.json. Updating would just be triggering a bower update.

[stefanpenner]

nice, thanks @rjackson !

[joefiorini]

Resolved, we will be using bower for managing ember versions