On launching AngularJS 1.2: what we learned, what we're changing

You might have noticed something new since we launched 1.2... Now that we're caught up, we've begun pushing a new release every week or two to stay on top of things and keep the PR queue responsive. Unless there's something big or noteworthy, we're also no longer blogging about every release.

We learned a lot from launching 1.2. Here are our own notes on the 1.2 launch process, and what we'll be improving, in case you're curious too.

1.2 took way too long!

• The community uptake and increase in github activity alongside 1.2 caught us by surprise. We got swamped, and it took some time to get on top of the new volume of contributions. We're back in the flow now, with a few new folks on the core team, and we're taking steps to keep from getting overwhelmed.
• To handle this new volume, we needed better infrastructure in place. We were depending too much on manual processes; managing them took time that couldn't be spent on development. We've since improved the CI server, and added more automation to our launch processes and tests. We're also looking for more ways of automating and streamlining the release process.
• Some of our 1.2 goals turned out to be much more challenging than we anticipated. Animations, for example -- we realized that we needed to do something different, to make it really easy to use by thoroughly anticipating use cases, instead of putting the burden on the developer to implement. Getting it right took longer.
• Our release schedule wasn't all that well organized. Because the core team was overwhelmed, we often sat on fixes and features for too long, delaying the feedback loop with contributors. We're generating pre-release builds from the CI server and working on providing them via bower (either nightly or even after each commit) so that we can get feedback faster.

Underscore issues and the revert in 1.2.1

Shortly after 1.2, we issued 1.2.1, reverting a late change around hiding "private" properties prefixed with an underscore. We tested the change on hundreds of apps at Google, and with a few minor exceptions, nobody was affected, so we assumed it was safe to proceed. But we missed the real impact on apps elsewhere.  We reverted the change within a week, but we'd like to avoid making the same mistake again.

What steps are we taking?

• We're committing to release more frequently, reducing the feature pressure on any one release.  With a consistent release schedule, we'll have more time to fully consider the implications of the features that we add and the changes we make.  
• New pre-release builds from the CI server provide greater visibility into what we're working on. No surprises.
• Even if the impact seems small, no more breaking changes in the last release before a final major version. We learned this lesson and we really mean it.