The problem with using such a specific URL is that Bower won’t be able to resolve the dependencies of multiple Ember add-ons that were built against even slightly different versions of Ember. That’s why dependency resolution systems use symbolic versions.
Given that Ember will be using a “no breaking changes, rolling builds” approach for v1.x, what does the team think of publishing a http://builds.emberjs.com/versions/v1.x/ember.js that returns a 302 to the latest v1.x release? That would at least let Ember add-ons depend on the v1 branch.
It still means they would have to do runtime checks to determine whether the particular version of Ember they’re running against has the features they need.
I am also using bower, I am using "ember": "1.0.0" as of now.
Since this brings the development, minified and production builds, it’s easier to configure a build pipeline for my app. I haven’t done it yet. I used generator-ember to bootstrap my project and got lazy to update my grunt configuration. There is an open issue to fix that there.
Additionally, if I use a URL, I don’t get any of the nested dependencies. Essentially, Bower becomes a glorified curl. The ember-cpm bower.json now looks like
Dependencies can be resolved with URL installs if the URL points to a tarball that includes the main path and bower.json. It might actually work for ember-dev to build these tarballs and put them on S3.
From what I can tell, however, such URLs cannot be registered with bower.
Not being able to register such URLs seems pretty bad. I guess the thing to do is actually maintain a separate dist repo, unless bower deals with this problem.
We are preparing to integrate the update of the default bower end-point components/ember into our release workflow.
Currently, that repo as tags for all of the major versions of ember since 1.0.0-pre. I believe that you can use something like the following for your bower.json: