@mcwumbly wrote:
Coincidentally, I was chatting about this topic with some folks the other day.
We were all devs who believe strongly in shipping continuously to our clients, but asked the question, "would we really want the same thing from the frameworks and libraries we depend on? Is there something different about framework-y code where shorter release cycles can actually be a problem?"
We started talking about how the majority of time spent dealing with framework code is split up among:
- gaining a high level understanding of the framework
- keeping up with changes and deciding when to pull them in
- updating individual dependencies when necessary, and dealing with incompatibilities occasionally
- searching google, forums and stackoverflow for specific answers
Number 4 is the one the generally eats up the most of our time when dealing with any given framework. We discussed some of the challenges of finding the right answers to questions in other frameworks we are using in current projects. In general, the feeling was that its much easier to find the right answer to a problem in opinionated frameworks with a certain amount of stability.
In other words, these three things all have to be true:
- Is this the same question?
- Is this the right answer?
- Is this answer relevant to me?
Opinionated frameworks increase the odds that the question is the same, and that the answer is correct. Stable frameworks increase the odds that the answer is still relevant.
Unopinionated frameworks greatly increase the time it takes to find a good answer.
I think that frequent changes also make this "find the answer I'm looking for" game much more difficult - and this is the biggest risk of the model.
It may be too early in Ember land to do this right now, but one possibility to keep in mind going forward is to have some kind of LTS release in addtiion to frequent, stable releases with new functionality. The LTS release would allow a critical mass of users to build community knowledge around a given version of the software over a period of time. The frequent releases would continue to allow an early adopter community to thrive and prove new features.
These three ideas really struck a chord with me as well:
In other words, I think the project could benefit from longer cycle synchronization points that the community can rally around and better support each other without having to upgrade to the latest stable release.
It seems like this sentiment is somewhat in line with the keynote from this years emberconf, but perhaps it should become a more conscious aim of the project for future major releases.