Monday, November 25, 2013

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.


  1. This is definitely not an easy task. Thank you for taking the time to explain the behind-the-scenes! :)

  2. Lovely guys, keep up the good work !

  3. Thank you for your enormous contribution towards moving the web forward. Keep up the amazing work!

  4. As a guide to others it'd be interesting to know how things go with automating the release process - are there standard stacks or setups that you tend to use or do you roll your own mechanisms? Looking forward to seeing the future updates as they arrive!

  5. Awesome :) I think it'll be great to have a blog post on the CI environnent. Nightly build with bower, can't wait.

  6. This stuff is not easy. You guys are doing a good job, and we appreciate it. Keep it up!!!

  7. Keep it up guys! can't wait for the next releases... It's an awesome framework!

  8. Please have even a small note in the blog about new releases and their change log. It's quite confusing when I find someone mentioning a new version number and I come to the blog and can't find it.

    Alternatively, maybe there's a way to be notified when new releases show up?

  9. I agree with Mohamed that a blog is a convenient way to announce releases and summarize notable changes/fixes, even if the post consists of just a few bullet points as a heads up. NodeJS releases quite often as well and their blog (when combined with a good RSS reader) makes it easy to keep up to date. It sucks when lots of little bumps happen on a project before you realize your several point-versions behind. It is much easier to learn about the improvements and changes to an API as they're happening versus cramming in many versions at once months later. Idea: what if a few volunteers took this responsibility on over time?

    1. Although a little hidden, GitHub provides a feed of releases if you won't to have it in your RSS reader:

      It does not tell you what has changed, unless that is put into the release note though.

    2. This page is a change log:

      Not sure why they don't at least link to this from the download page.

  10. Question concerning the now frequent point releases:

    Aside from the "revert hiding private properties" thing -- because I think that was a good call to clean up the release mistake (since it was never RC'ed -- can we develop against 1.2.x and assume that there will be no intentional breaking changes in the x releases? Will the team be (knowingly) deviating at all from semver best practices? If I've overlooked a statement on this subject please point me to it! :)


Note: Only a member of this blog may post a comment.