-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do not use bower for managing ember versions #25
Comments
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... |
But other deps might depend on ember, with version deps.. |
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 |
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. |
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. |
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 |
nice, thanks @rjackson ! |
Resolved, we will be using bower for managing ember versions |
As great as bower is, it's been a small hell for managing ember versions. For the majority case, where you are always on the release channel, it's probably okay. Once you stray from that, however, it's very difficult. Also, ember-cli is bringing its own updater for ember & ember-data. @stefanpenner Are you cool if we don't use bower just for the ember/ember-data dependencies in apps?
The text was updated successfully, but these errors were encountered: