Fog Creek Software
Discussion Board

Steps leading to software release


So you have done all your development.  Your code is tucked away nicely in CVS.  My question is what are the best steps to take with regards to releasing?  Should one implement a code freeze and halt all new development?  Should one split the crew into new development vs bug fixes, or should all developers be spending half their time on bug fixes?  What milestones would you set?  How do you deal with the extra testing that's required to make sure that there are absolutely no holes?


Tyson Haverkort
Thursday, February 6, 2003

Whatever you do, document every step you take so if you have to do it again, you remember all the little things you need to do (like updating version numbers, copying files, etc).

Michael H. Pryor
Thursday, February 6, 2003

A popular model around here is:
1. When you get close to the end of the development cycle (feature complete, no major bugs), you create a branch in CVS for the "release". As soon as that branch is created, only approved changes are allowed on it (fixes for bugs that need to be fixed for that release).

2. While those last few bugs are being fixed (and testing is being completed), developers with no more work to do for this release go back to working on the main branch, developing features for the next version.

3. When the software on the release branch is ready, you tag it with an obvious tag, then build it, and go through your final candidate testing.

4. After the software has been released to customers, do a merge of any bug fixes from the release branch onto the main branch.

(repeat as necessary)

As far as who should work on bug fixes versus next version features, try to have everybody contribute to both.

Take the effort to automate as much testing as you possibly can, it makes the release process much less stressful.

A previous poster mentioned documenting everything you need to do for the release (setting the version number, etc). I'd go one step farther than that - make sure that your daily builds go through all these steps automatically, including setting the version number to something different for each build.

Right now, I can look at any output file from any build I've done in the past 6 months and tell you exactly what tag in CVS was used to build that software. That makes tracking down regression bugs much easier.


Mark Bessey
Thursday, February 6, 2003

Nice description Mark...

Nat Ersoz
Thursday, February 6, 2003

Sorry to rain on your parade, but this is an absolutely silly question.

Is this an MP3 player you're writing for your girlfriend or the control system for a manned space vehicle?

There's no reasonable general answer to your question.

"It totally depends."

Thursday, February 6, 2003

>>Sorry to rain on your parade, but this is an absolutely silly >>question.

And I am humbled by your profound answer.

Thanks Mark, that was pretty much what I was looking for.  This is also the model we've followed.  I found the merge process a little painful due to the fact that the majority of developers were on the main branch writing new code during the code freeze.  I was looking for some ideas on how to make the next release less painful.  Maybe the trick is to keep the time between the code freeze and the release as short as possible (at the expense of new development)?

By the way, it's actually a MP3 player for a manned space vehicle.

Tyson Haverkort
Thursday, February 6, 2003

Personally I look forward to MP3 players for robot space vehicles.  With skinnable UI of course.

Simon Lucy
Friday, February 7, 2003

I think Mark has made some good points that can still be applied to your knocked-off-in-the-afternoon MP3 player, albeit on a much lower scale.

Suppose you knock off version 1. Great. Then Girlfriend complains cause she can't do playlists. Hmmm, better go fix that. Then Girlfriend finds a bug which stops large files from playing properly. Oops. Better retrofit that in ... except you're halfway through doing the playlist feature and the retrofit's a complete nightmare.

So there you go. Still possible to screw up on a one man team doing a low quality project.

Better Than Being Unemployed
Friday, February 7, 2003

Merging changes from a long-lived branch back to the (continuously-changing) main development trunk seems to be one of the "hard problems" in Configuration Management, as far as I can tell.

It's inevitable that eventually the changes you've made on the branch simply won't apply back to the main development sources anymore. If the function you changed doesn't even exist anymore, it can be a lot of work just to find out where that patch needs to go, much less if it's still relevant.

Most groups that I've worked with tend to try to minimize the amount of time anybody is working off of the main branch. Here are some other  policies that you can try, to minimize conflicts.

1. When you fix a bug on the branch, immediately fix it on the main trunk as well. Most developers don't like doing this, because it interrupts the "flow" of work, and it seems like wasted time. It also gets progressively harder as the branch diverges. But for short-lived branches, it really is the easy way to go.

2. Mark each and every bug fix with a comment that identifies exactly what bug this fixes (usually with a reference to the bug tracking system), and identify where the bug fix starts and ends.

3. Learn how to use a three-way merge tool. This makes it a lot easier to identify which changes were made on each branch.

4. If the main trunk is always in "shippable" condition, then the requirement to work from old versions is reduced. This is one of the best ideas in the Extreme Programming methodology. Unfortunately, the effort required to transition to this model makes it hard to do so with an existing project. Maybe next time...


Mark Bessey
Wednesday, February 12, 2003

*  Recent Topics

*  Fog Creek Home