Conversation
|
let's not include the addons part by default until we've verified it to work with all common ember/template compiler versions. |
|
Ok. How much more work is left? |
|
Not entirely sure yet. If we want 100% reproducability, we'd have to make containers for every patch-level version starting at some point. For simple poc stuff we could also get away with minor-version-level containers (2.4, 2.3 etc) |
|
@rwjblue you probably have more insight into this. Basically we have a couple of components:
How important is it that their patch versions are in sync? Or can we get away with similar minor versions but different patches (eg. build an addon in 2.4.4 and have the twiddle running 2.4.5) |
|
Using a 2.4.0 template compiler with 2.4.5 is not guaranteed to work. We only publicly support using the specific template compiler that is paired with the ember build being used. In a few circumstances that I am aware of template compilation changed in a point release (twice for security patches and once due to other non-security related bug). |
|
@joostdevries So we need a backend design that either (1) doesn't require different containers for different versions of ember or (2) can create containers on the fly. (1) Sounds easier, after all, ember and ember-template-compiler are just gotten from a bower component. ember-cli version in the addon builder should not matter, but I would prefer to use a more recent version than 1.13.15 to do the building if possible. |
|
We also have to figure out what to do about the "special" versions for release, beta, and canary. I'm unsure how to cache the addon build for those, as they change often... |
|
@rwjblue For canary we have to expire the cache how often? Or just never cache? |
|
Every commit to emberjs/ember.js#master |
|
@joostdevries We can choose not to support "release", "beta", and "canary" ember versions initially. |
3 participants
No description provided.