@domchristie wrote:
I feel like the the two are inextricably linked:
Either the changes are too big to be documented in time, or the release cycles are too short, or perhaps both.
If I were to start this topic again, I’d probably re-title it “Issues with the release cycle” (or something). I suppose my point is that, the framework has gone through some pretty drastic changes in it’s short lifespan. Whilst the API has been developed in accordance with semantic versioning, it hides the difficulties in experience of developing Ember application. This is addressed by @wycats in the release cycle RFC section: Problems with the 1.x Model:
While the SemVer guarantees promise that your code will continue working, they do not address changes to idiomatic Ember usage, which can change over time. In practice, this means that there can be churn in the experience of using Ember without actual breakages.
This is exactly what I’m getting at, so it’s great to hear it being addressed. I probably go a little further and rather than calling it “idiomatic Ember usage”, call it “core Ember concepts”. Ember is looking like quite a different framework to what it was a couple of years ago. Take Components for example. Components did not exist in the framework until 1.0 RC6, almost a year after 1.0 pre, and therefore weren’t considered to be central to the core concepts. Now they are set to take a much larger role. (Granted, this was pre 1.0, but it demonstrates the issue.)