"Ember is released in "revisions", because it's not production ready and not ready to be 1.0. Hence the core team chose to rather call breaking changes a new "revision". Well guess what dudes, that's exactly what versions are for. Why couldn't you just like normal people release 0.4, 0.5? Why do you need to hit 1.0 directly?"
Why doesn't he get more involved in the project and stop complaining. Yes Ember is lacking in the prioritizing department but it's a community project and there is always room for more people.
There are a number of forks/patches out there that provide hasOne semantics and saving for multiple records in the same commit (ours are the mhelabs ones)
Comments
I think this guy has a point with:
https://github.com/emberjs/ember.js/commits/master/ember.jso...
"Ember is released in "revisions", because it's not production ready and not ready to be 1.0. Hence the core team chose to rather call breaking changes a new "revision". Well guess what dudes, that's exactly what versions are for. Why couldn't you just like normal people release 0.4, 0.5? Why do you need to hit 1.0 directly?"
Why doesn't he get more involved in the project and stop complaining. Yes Ember is lacking in the prioritizing department but it's a community project and there is always room for more people.
There are a number of forks/patches out there that provide hasOne semantics and saving for multiple records in the same commit (ours are the mhelabs ones)
- https://github.com/mhelabs/ember-data/tree/has_one
- https://github.com/mhelabs/ember-data/tree/parent-child-comm...
- https://github.com/ghempton/data/tree/relational-adapter
This just goes to show that there is so much more than a feature-list to consider when selecting your stack.