There are features missing, so we start at 0.0.1-alpha1 …

There are thousands of projects, which have a version number that starts with a zero. It was common to do so many years ago and strangely enough, there are still projects that do this today. During the “Web 2.0″ hype it was even en vogue to put “beta” stickers in the logo, so the “unfinishedness”  was promoted to a positive signal that expressed that the project was dynamic and evolving. While that point of view is somewhat understandable, it’s somehow “dangerous” too. People often don’t take projects with a zero in front not seriously. Many projects even classify their status as alpha or beta for many many years. Nevertheless, they release new versions to the public from time to time. How can this be, if the project is not ready for use?

A common misconception is that a project that releases something with a 1.0 is finished or has completed the vision for the project. Another “advantage” of the leading zero is that you can react to critics that the project itself is not finished and the complains will be resolved when 1.0 will be released. But are there critics that complain in this way and if there are, do they really buy the argument that this is due to the beta status?

I think not! When you are so satisfied that you want to release a stable version to the public (I exclude “real” beta versions and release candidates here), then you should consider to start with a 1.0 when you use this kind of version number scheme. It’s not a problem if a 1.0 release is not feature complete, that is what future releases are for. Just use 1.0 for the first release where your software does something useful (otherwise it wouldn’t make much sense to release, doesn’t it?) and then go up from here in your self defined steps. The common scheme is #major.#minor.#patch, where #patch is increased by (security) bugfix releases, #minor is increased when smaller changes have been made that are usually compatible with the prior releases with for example saved files, interfaces, … and #major is increased by big changes that the team considers as big step ahead. New major releases are also a good point in time for breaking compatibility or getting rid of deprecated stuff.

Using a reasonable version scheme with appropriate numbers, people will take the project more serious, business users won’t get a headache when they have to convince their boss that the 0.0.1alpha3 version of your project is more stable and reliably than the version number suggests. Don’t get me wrong, a version number does not make the your project more reliable, stable or whatever, it just changed the perception of the project and provides a more professional “look”.

Alternative schemes

Another thing that has established at least in the last decade is that major or sometimes even minor releases get code names that make them memorable. Ubuntu for example uses alliterations like Karmic Koala, Dapper Drake etc. to name their releases (major + minor according to the scheme above). KDE has code names for their beta series for a release. This makes it a lot easier in communication with your users and within the team to speak of the karmic release than release 10.04 or the 1.2.x series. Some projects follow a strict pattern in choosing their release names, for example Debian uses toy story character names, if you need plenty names, you might want to have a look at names appearing in the lord of the rings series. ;-) Another reason for assigning names to releases is as reminder of project members that died, this has happened to the postnuke project and the next series was named the “Adam Baum” (Greg Allens pseudonym) release. He lost his life in motorcycle accident.

Another thing that might be worth mentioning is that there are more schemes than the major.minor.patch scheme. The decision whether a new release is a next major release or just a minor or maybe even if the minor version should be raised by two or more may take quite a lot of time and some people are really serious in this area and escalate this decision to a full blown conflict. You might also just use the year and the month as version number or year and a running number for the releases of the year, example ubuntu like #year.#month (9.10, 10.04, …) or #year.#counter (10.01, 10.02, 10.03, …). This has the advantage or disadvantage (depending on your point of view) that people see in a glance how old the release is, so this may be only usable when you have a more or less steady release schedule with at least one release per year. I like it for projects with a  high visibility, small tools won’t benefit from it, but it’s worth considering, when you plan your release strategy and decide the version number scheme.

One last thing about creative version number schemes…
Don’t use only code names or start decreasing version numbers without a reason or you will bring projects like the linux distributions into trouble, because their package managers depend on version numbers that are only increased. Otherwise their update functions will fail. This also is a problem when you’re changing your version number scheme after a while, so don’t forget your distributors!

Conclusion

Version numbers are not an easy topic, implications on the perception of the project are not always as easy to grasp as we’d like to. So spend at least little time when the project starts to release stable versions. 0.x version numbers and beta stickers are out. People like reliable software that takes itself and it’s users serious.

Finding your perfect release cycle

Most projects have a “on demand” release plan. When security problems occur or a stable application has been build, then a release is quickly announced and put online. This is ok as long as it is a smaller project. Especially when your project is used in a business environment, people will ask for plans and schedules so they can plan their updates. Another problem with irregular release schedules is that when the last release has been a long time ago, then people might get impatient and start to use your daily development exports or use a checkout from the version control system, that you are using (I hope). The problem is that the impatient users will lead to more and more support requests, because they are using a version that is not released yet.

So what to do? Communicate your plans early. People like to be informed. When your plan for the next release does not take the expected 6 months and after 2 years you’re not ready, then you should consider to change your plans and try to do intermediate releases. When you are planning big changes, then it’s a good idea to check if you can split your changes into smaller pieces to keep the time between releases smaller.

When you have enough time to dedicate for the project or you have a group of people that helps you to have a more or less constant stream of changes then you might consider to establish a regular release cycle like for example gnome or ubuntu (they release every 6 months). Sometimes it’s easier to determine the changes that fit in a release cycle than to determine how long a set of changes will take. The advantage is that you might even skip some changes when time is running short.

Presumably dead projects

As mentioned above, sometimes changes take longer than expected. The planned release takes a year or two longer and you’ve pulished none or just a few intermediate bugfix of feature releases. The effect is that your userbase might shrink, people start complaining, maybe even start a fork to return to a steady release cycles with more releases per year. There is also an effect on the team. Maybe not your whole team is involved in the blocking task(-s) that lead to the delayed release. They want to continue, but their tasks might not be ready when the current blockers are finished, so they are asked to wait to not destabilize the code base even more. That leads to frustration even in your team and may damage the team on the long run.

How to deal with complex changes

So there are changes that are small and medium sized and of course the big tasks that take virtually ages. How should you deal with that? No matter how good you plan there were always tasks that have a high probability to break your release plans. To solve this you can use techniques that are commonly used in “commercial” software development: feature branches!

Every version control system that I know of has the ability to copy a repository or a part of it (this is called branching) and there is another functionality called merging where you can merge the changes of one branch in the other branch and solve any conflicts where the same code lines have been changed. I don’t want to go too much into detail here, because it depends on the software you are using, but when you use this for any non trivial changes in your project, then it’s not a big deal when you are used to it.

So, how does this work? You have a main development branch which is usually called “trunk”. You plan for example to refactor a part of the system, then you branch the trunk and work on that branch on your refactoring. The rest of the team can do for example smaller changes or bugfixes on the trunk  or even other feature branches. When you like you can pull changes from the trunk in your branch if you feel that this is necessary. When you’re done, then you can merge your branch back into the trunk and your project has a shiny new feature or a cleaner codebase. The downside of this is that, when you have changed parts of the code and in the trunk people changed the same code pieces, then the version control system will complain and mark the file as conflicting. These conflicts have to be resolved manually. This happens in my experience not very often and when it happens it’s trivial to merge the changes and get the code running again. The chance of conflicts grows over time, when work is done in the trunk and the branch, but by pulling updates from the trunk in the branch you can minimize the chance of conflicts.

People often complain that this is too complex, they don’t know hot to do the branching and merging and they don’t believe in this anyway. Where does this come from? I think the answer is simple. When you don’t do branches, then you’re not “wasting” your time at the start by performing the branches and later when the merging occurs. But they don’t see the big picture. Development gets even easier when you do when you do this. You get used to branching and merging pretty soon and it’s not something you have to think a lot about. Everyone can develop their features without interfering too much with the rest of the team and when a feature is not ready when the planned release date approaches you can simply move it to the next release. So the whole team benefits from it, don’t get intimidated by some devs that are complaining. They’ll get use to it. ;-)

Condclusion

So, what have we learned here? Release plans are only as good as the techniques, you use to stick to them and purely code driven release schedules tend to get blown away by too complex tasks that have been underestimated. Use things like branching and/or discipline to establish a regular release schedule or at least be predictable and communicate your plans to give your users a chance to react, plan and look forward to your releases.