Kephra - Thoughts - Versioning

Releasing in numbers

From the beginning I wanted clear and understandable version numbers. But this is not a question of digits, but of release cycles, because counting them is a concept that is understood very well. These cycles have to fit to our developer team and our goals to produce something well polished and rock solid. On the other side I also want to communicate any changes as fast as sanely possibly and have a scheme that can display progress realistically. But you can't have all at once, or at least you have to study the upcoming problems carefully to make a good choice.

Goal vs. Good Enough

Free software development is often driven by a longterm vision or some (often) technical goal. The releases toward this goal are counted by the second digit after the first point. Only if a new vision is realized, the software has some new foundation or is largely rewritten it gets the number 2.0. On the other hand commercial development is mostly driven by the impression it tries to give its audience. So each new version is marketed as the shiny new thing with a new first digit or even a new name or at least some additional letters to identify this special release. Large software packages know sometimes incremental steps, or minor releases are presented as free bonus. But by in large do companies promote their products as large achievements and big releases without a dot after a number.

I don't have a clear and detailed vision but I know in general what I wish and whats missing in most other editors. To me marks 1.0 a level of satisfaction and feature completeness I dream of. Because the way toward it is not the shortest, every sub release with one dot will be stable, polished and in itself complete.

Maybe this scares some people away, that think 0.n versions are just a beta or not that evolved. But I can't think of any good intermediate goal. Maybe when the 5 core extension I need are ready to use (library, command line, debugger, source outline, file/project/version control manager) there will be a 1.0.

Feature vs. Time

Another decision one have to make is between releasing when a feature is ready or releasing on a time schedule. The ladder became more popular among projects like Linux and parrot and I agree that having regular releases is a strong signal that this project is alive and that you can depend somewhat on the work done here. It also helps to schedule and organize things that relate to that project. On the other hand I want to have for any testing release at least one bigger feature that teases people to use those versions. If that feature gets stable, this release will be shipped. And because after several test versions comes the stable this will always bring several new things. But if, for whatever reason, no larger improvements seen daylight I want to have a stable release every year or half, a testing release every 2 or 3 month.

Stability vs. Development

That is another big one and has do with the question to release on time or when every problem is shaken out. While a testing release may have some minor problems, a stable never should have known issues. But even if you have a decent test suite, many bugs will be found when a version is out. Thats why we make testing versions, to catch as much as possible bugs before the audience can see them. But because the main audience are much people, many bugs will be found when the stable is out. Our "no known issues" demands to fix that immediately. But under which number? The regular development will be long gone to further counting (e.g. 0.4.0.11). Backported bugfixes are no regular development and should be also counted in a different way. The end user also should have his version with a short and sweat number like 0.4. So we add a patch level ("pl" in short) that will only appear on the download page and the info box. The user can this compare if an issue is fixed in his version of 0.4 but most of the time just use "the" 0.4 version. In summary: I am very concerned with stability but version number have to count the development. There will be no release candidates or beta versions just test releases, that might have issues but will not crash at the best of our knowledge.

Version vs. Revision

In some info boxes can also be found revision numbers, but i don't prefer them. Together with the version they are too long and it doesn't says much at all. With Perl we also don't compile and and don't need the info, what is bound with what. SVN counts revisions for us. If we make a release, we mark it in the RCS, not the other way around. But indeed the steps between test releases are large. Enough to justify a fourth cycle that counts important commits. Testing releases will be available like stable, but for the dev team, friends and hardcore tester we release nightly versions on a separate site. This will be helpful to have even more testing and better coordination inside the dev team.

Conclusions

I'm overall happy with the described model, because it does focus on what is important to me and enables quick development (no stable branch). It has 4 level of release cycles. Each for a distinct different purpose, so that the length of a version number can tell for what audience it is made and what to expect from it, without having much additional marks and letters.