Wed, 14 Mar 2007
I suspect that the most popular of the software I have written is Devel::Cover. Devel::Cover is the Perl code coverage module. The first release was 0.01, and it escaped into the wild (aka CPAN) on 9th April, 2001, so the software is now almost six years old.
The current release is 0.61 and that does actually represent 61 releases. Since the very first release, the README file (and the pod for the main module, from which it is generated) has included the sentence:
If you can't guess by the version number this is an alpha release.
When I wrote that sentence it was very obvious to me what it meant and it never occurred to me that it might have a different meaning for other people. I have also never considered removing the line from the documentation, and I'll explain why later.
However, in the subsequent six years, I have noticed many people asking whether this meant that the module wasn't in a state where it could be used, or some similar question. Others have normally answered this question stating that the software has been working quite well for them, and I have been happy to leave things at that.
But today, as the question was asked again, I did something I should have done five years or so ago - I actually thought about the reasons behind the question.
And here we come to the crux of the matter. What does an alpha release actually mean?
To me, alpha releases, beta releases, release candidates and full blown releases come with a specific set of expectations, and the version numbers of the releases serve to confirm those expectations. I thought these expectations were common when I first started writing software, but it now appears that I might be clinging on to a minority view.
The key word in these expectations is interface. In an alpha release you can expect the interface to be unstable. That means that the interface may well change between alpha releases without warning.
In a beta release the interface should be stable. Wider usage and more thorough testing of beta releases may show problems, the resolution of which might involve an interface change, but that should be the exception rather than the rule and would probably involve returning back to alpha status until the new interface was considered stable again.
A release candidate should be just what it says, and if no problems are found it should become the actual release. And a release itself should be stable software, properly tested and with all the advertised features required to make it useful.
There are almost as many versioning systems as there are developers, and I'm not overly concerned about their details, provided they are consistent. But one aspect of the versioning system should hold - an increase in the major version number should indicate a backwards incompatible change to the interface. Otherwise interfaces should be backwards compatible across the same major version.
[ Note: Some version systems, such as that used by perl, for example, may choose slightly different semantics. In the case of perl, the system is Revision.Version.Subversion and the promise is made that compatibility is maintained across Revision.Version. But since Perl 5 is over 12 years old, the effect is much the same. ]
Notice that these definitions only talk about interfaces. Specifically they do not talk about features, quality or bugs, with the exception that a full release would be expected to have a reasonable quality.
But it seems that nowadays, in general, that is all that these terms are expected to mean. Wikipedia, for example, (the fount of all knowledge) states:
The software release life cycle is composed of different stages that describe the stability of a piece of software and the amount of development it requires before final release. Each major version of a product usually goes through a stage when new features are added, or the alpha stage; a stage when it is being actively debugged, or the beta stage; and finally a stage when all important bugs have been removed, or the stable stage. http://en.wikipedia.org/wiki/Software_release_life_cycle - 2007-03-14
Whilst it is true that the stability of the software will generally bear a relationship to its status, I think that this description completely misses the point. But it gets worse:
The alpha version of a product still awaits full debugging or full implementation of all its functionality but satisfies a majority of the software requirements. It often lacks features promised in the final release but demonstrates the feasibility and basic structure of the software. Ibid.
No wonder people wonder whether it is safe to use my software!
Nowhere in the Wikipedia article is the word interface even mentioned, except to say that Microsoft included user interface changes during their public beta testing phase for Windows Vista. One could argue that stability includes the idea that the interface should be fixed, but the article seems to equate stability with a lack of bugs.
Now I'm not really picking on Wikipedia here. The article just seems to be reflecting the predominant perception of these terms. What really surprised me was how hard I had to search to find anyone holding the same opinion as me. To be honest, I didn't really search all that hard, but then I hadn't expected to have to search at all hard, and I did only find one reference, which was to the Python version number scheme:
Alphas are early releases in which interfaces aren't yet finalized; it's not unexpected to see an interface change between two alpha releases. Betas are more stable, preserving existing interfaces but possibly adding new modules, and release candidates are frozen, making no changes except as needed to fix critical bugs. http://www.python.org/infogami-faq/general/how-does-the-python-version-numbering-scheme-work/ - 2007-03-14
So it seems that most people consider alpha software to be incomplete and full of bugs, and beta software to be what is given to the public to do the testing. I suppose that's not too surprising given the state of much released software, even software which costs a large amount of money, but it really isn't what I mean when I use these terms.
When I say that Devel::Cover is alpha software, what I mean is that I may still change the interface to it. Over the last six years and 60 releases I've been pretty good at not changing the various interfaces, but there are some that I don't particularly like, and as soon as I come up with something better (or if I'm lucky someone else will do this) then I want to be able to change the interface without having to bump the major version number.
I also mean that there are some features missing that I would like to add at some time, and that there will be bugs so don't get upset if you find one, but mostly I mean that the interface might change.
It's really not a big deal, but since I don't have a marketing department telling me that I have to have a new major release in time for a certain trade show and that it must include the following check-box features because the brochures have already been printed and the press release has been sent out, then I'm happy staying at an alpha version until I really am happy with the interface.
And anyway, if being in perpetual beta is a mark of being Web 2.0, surely being in perpetual alpha is a mark of being Web 3.0, which puts me well ahead of the game, even six years ago.
That's why Devel::Cover is still alpha software, and that's what being alpha software means for Devel::Cover. Since I now realise that this is probably not what most people understand when they read my documentation, I'll just have to explain things in more detail. I suppose I should really be glad that not too many people read the docs.
