Every Two Weeks

Our most popular gems—paperclip, capybara-webkit, factory_girl, and clearance—will see new releases every two weeks.

Trying to be reasonable

Release early, release often. In the past we’ve often released new versions of gems in a “when we feel like it” fashion: either we needed the gem to exist for a personal project, or we’re proud of some change we just made, or someone complained to us about an old version. This lead to a problem: when we were just taking pull requests we didn’t think to release a new version.

By setting up a regular schedule this means that contributions will be more public more quickly. We chose two week cycles as a compromise between releasing very often (every time we take a pull request) and in a wide duration (every three months). Too often and we’d annoy people when they upgrade; too infrequently and the bugs are simply not being fixed for the largest number of people.

It’s a process

Setting aside time to make a release elevates it from “OK I made these changes gem push woo!” to “I am going to make a proper release”—it reifies the release as a first-class action for us to concentrate on. Changelogs, blog posts, and tweets are side effects of putting the right amount of care into releasing a new version of a gem.

When‽

Factory Girl (factory_girl and factory_girl_rails) and Paperclip are on a two week release cycle starting January 27th, 2012. Clearance and capybara-webkit are on a two week release cycle starting February 3rd, 2012.

You can track gem releases using the RubyGems Web site and your favorite feed reader. It’s like this:

1. Sign up for RubyGems, or sign in if you already have an account.
2. Navigate to the page for the gem you care about.
3. Click “Subscribe”.
4. Click the “Dashboard” link at the top of the Web page.
5. There’s a sweet orange RSS icon in the middle of that page. Subscribe to that link!

When you say “every two weeks”…

Sometimes it doesn’t make sense to cut a release only every two weeks. Important security fixes or bugs that block everyone from using the gem are examples where getting something out as soon as possible is the only way to do it. On the other hand, sometimes there simply haven’t been any changes.

If we release a new version of a gem on the 26th and the 27th is when a scheduled release is to happen, it’s likely that we’ll skip the schedule. In general we’ll continue the “do I feel like making a release?” thought process, but every two weeks and with a bias towards a positive answer.

Or whenever

The bi-weekly cycle is new and, like everything else in software and life, worth reconsidering at all times. Please let us know if it’s too often, too seldom, just right, or completely useless to you!

Twiddle Wakka

Do you know the twiddle wakka? It looks like this:

~>

You’ve seen it in your Gemfile. Here’s an example

gem "rails", "~> 3.0.3"
gem "thin",  "~> 1.1"

~> 3.0.3 means that when you bundle install, you’ll get the highest-released gem version of rails between the range >= 3.0.3 and < 3.1.

~> 1.1 means that when you bundle install, you’ll get the highest-released gem version of thin between the range >= 1.1 and < 2.0.

I learned the name “twiddle wakka” at Jeremy Hinegardner’s Rubyconf 2010 talk, Anthropology of Ruby. During a data-driven analysis of the ecosystem of Rubygems, he found the twiddle wakka is used infrequently and asked the Ruby community to use it more.

Using the twiddle wakka in combination with consistent MAJOR.MINOR.PATCH versioning by gem authors, we can achieve better stability in our dependencies. Jeremy suggested reading two documents on consistent versioning:

• Apache’s version numbering
• Semantic versioning

In the comments of this post, David Chelimsky suggested a related document that is particularly relevant to us as Rubyists:

• Rubygems Rational Versioning

I think most people are in favor of this in principle but are not consistent in practice. This leads to confusion: “Which libraries are consistent and which aren’t? Is this gem safe to declare as a dependency at the major, minor, or patch level?”

It seems like a simple way of clearing up the confusion is for authors to declare their intention of consistent versioning by using the twiddle wakka in their README’s installation instructions. If I see this…

gem "clearance", "~> 0.9"

… then, I feel the author is assuring me of the “safety” of this gem at the minor level.

Therefore, I’m editing the READMEs of our gems to declare our intention. Some may be “twiddle wakka’ed” at the major level, others at the minor level, and others at the patch level. That seems like a reasonable compromise to me since every project is at a different stage.

I’ve been guilty of being inconsistent about this in the past. Call it a New Year’s resolution, but I’d like be better about it in 2011.

What do you think? Is this README idea any good? Are you going to do the same?

Widgetfinger: Versioning and Google Apps Support (or, how I learned to stop worrying and love Google Apps)

We’ve rolled out a few updates to Widgetfinger, our simple content management system for simple websites, and we wanted to tell you about them.

Content Versioning

The biggest change is that you can now review and compare past revisions to your content.

The special treat here is that we’ve actually been tracking every change since Widgetfinger launched last year. When building Widgetfinger, we realized after we started work on the Revisions functionality that it shouldn’t be a feature for v1. Since most of the code was in place, well tested, and functioning, we decided to leave it in place so that when the revisions functionality came back up to the top of the priority list, we’d roll it out with access to all prior revisions.

Support for Google Apps

The other new feature we’ve rolled out is built-in support for Google Apps when using Widgetfinger DNS.

Widgetfinger is meant to take over responsibility for the hosting of your simple “brochure” type website, and that includes Web Pages, DNS, and Email. We’ve had some requests to use Google Apps instead of the built in email hosting, and we’re now happy to oblige. Enabling this for your site is as easy a signing up for Google Apps and checking a checkbox in Widgetfinger, and providing the ‘finger with your Google Apps verification code.

Doing so will cause the proper DNS entries to be created to fully support Google Apps for email, calendar, and the other Google Apps services. For more information on how to set this up, see the Widgetfinger help section on it.

Let us know if you have any thoughts about this or any other Widgetfinger features, we love to hear from you. If you’ve never tried Widgetfinger before, we encourage you to give it a shot, and let us know what you think.