How do you release software?

The traditional approach to software release is to make a list of features estimate how long it will take, and plan accordingly.

There’s one caveat, though: in software development, it’s tough, if not impossible, to know how long a feature will take. The Mythical Man-Month goes into great length about the difficulties of planning, and most of it boils down to the fact that you don’t know what a features entails until you do it.

The problem with that approach is thus that sticking to the schedule is hard, and often results in delays and unnecessary pressure on development teams. A fixed schedule also prevents you from working on something that may turn out to be critical to your customers.

The other approach is to time-boxing: release at a specified date whatever is finished.

You always release on time, and within a development window, you can reprioritize features as needed.

Customers know when to expect a new release, developers are less stressed about having their feature “in the release,” etc.

Why we change to timeboxing

QuasarDB was usually released using the former method for mostly historical reasons. Our historic customers would upgrade maybe once a year, tops. As we grew, however, customers asked for more features, shorter release cycles… Our old release model quickly started to crumble.

That’s why we’ll now have one release every first Monday of the month, and a release candidate every third Monday of the month.

In other words, you’ll have to wait half a month, on average, to have a new version. It also means, for us, more efficiency and not to have too worry about a release being “too old.”