cURL and libcurl

200 OK

6 Comments

One day in March 1998 I released a little file transfer tool I called curl. The first ever curl release. That was good.

10

By the end of July the same year, I released the 10th curl release. I’ve always believed in release early release often as a service to users and developers alike.

20

In December 1998 I released the 20th curl release. I started to get a hang of this.

50

In January 2001, not even three years in, we shipped the 50th curl release (version 7.5.2). We were really cramming them out back then!

200

Next week. 23 years, two months and six days after the first release, we will ship the 200th curl release. We call it curl 7.77.0.

Yes, there are exactly 200 stickers used in the photo. But the visual comparison with 50 is also apt: it isn’t that big difference seen from a distance.

I’ve personally done every release to date, but there’s nothing in the curl release procedure that says it has to be me, as long as the uploader has access to put the new packages on the correct server.

The fact that 200 is an HTTP status code that is indicating success is an awesome combination.

Release cadence

In 2014 we formally switched to an eight week release cycle. It was more or less what we already used at the time, but from then on we’ve had it documented and we’ve tried harder to stick to it.

Assuming no alarmingly bad bugs are found, we let 56 days pass until we ship the next release. We occasionally slip up and fail on this goal, and then we usually do a patch release and cut the next cycle short. We never let the cycle go longer than those eight weeks. This makes us typically manage somewhere between 6 and 10 releases per year.

Lessons learned

  • Make a release checklist, and stick to that when making releases
  • Update the checklist when needed
  • Script as much as possible of the procedure
  • Verify the release tarballs/builds too in CI
  • People never test your code properly until you actually release
  • No matter how hard you try, some releases will need quick follow-up patch releases
  • There is always another release
  • Time-based release scheduling beats feature-based

6 thoughts on “200 OK”

  1. > Time-based release scheduling beats feature-based

    Daniel, do you have any insight on why time-based is better? Or maybe examples of how?

    1. I prefer it for two reasons:

      1. We don’t have to wait for feature X to be completed or work to ship a release, so
      2. Keeping the release dates is much easier and makes them predictable and reliable

      1. Releasing on features was what made haproxy-1.5 take 4.5 years instead of the expected 6 months. You can’t decide what comes in parallel to your work and that perpetually prevents you from making progress towards your release. Worse, once some developers figure you’re facing difficulties, they conclude the next release is not for now, so they figure they probably still have time to develop their stuff and get it into that release!

        With a time-based approach it’s easier to have phases in the development cycle (less sensitive changes, cleanups, etc) and contributors understand that there are periods where you won’t review their possibly breaking changes.

        I wouldn’t go back to feature-based for any reason!

  3. Dainel, I 100% agree with your “lessons learned” conclusion, I’m having the *exact* same ones on haproxy.

    I also wanted to live-test releases done by someone else, it’s very instructive, you should try once, I basically discover two things:
    – things that are not written in your procedure but that you happen to know and are not obvious to others
    – permission issues.

    After that you feel way more relaxed, knowing you’re less critical for the project. I’ll keep that live test running at least once a year or so to continue to avoid the “what if” class of questions.

Comments are closed.