What should the next version number be?

We have noticed that some people have been getting a little confused with NVDA's current version numbers. I have also been wondering about them, especially in regards to the closely approaching next stable release.

As a bit of a background: We released NVDA 0.5 in Mid 2007. We then started planning for 0.6. Very early on in the creation of 0.6 we massivly improved support for Mozilla Firefox (introducing the new virtualBuffers). However at the same time we started neglecting the code for Internet Explorer as the NVDA developers mostly used Mozilla Firefox.

In early 2008 we thought it would be good to release a new version, though we knew that Internet Explorer support rather than being better, was getting worse. Because of this we were not willing to release 0.6 until we had fixed these issues, or in fact completely rewritten Internet Explorer support so that it matched the support for Firefox.

We decided to make some "preview" releases of NVDA before 0.6 so that people could try out what we had achieved so far, but with out saying that we had actually achieved all we wanted. In March 2008 we released 0.6p1, in August we released 0.6p2, in December we released 0.6p3 (and because of a few critical issues, we released 0.6p3.1 and 0.6p3.2 over the following months or so). The p in these versions stands for 'preview'.

After 0.6p3.2 we have been able to improve a lot of things in NVDA, such as:

• Complete rewrite of Internet Explorer support (closely matching Firefox support).
• Rewrite of Adobe Reader support.
• Support for Windows Logon and Vista UAC screens.
• An elements list for web pages allowing you to list links, headings and ARIA landmarks (replaces the older Links List).
• Support for the UI Automation accessibility API in Windows 7.

Not to also mention the more recent changes which move the location of NVDA's configuration file for portable copies, makes NVDA much more accepting of configuration errors, and allows the loading of custom appModules, brailleDisplayDrivers and synthDrivers from the user's configuration directory. Because of these things, we feel that we are getting rather close to another stable release (a release to fully replace 0.5).

However as the changes are rather huge, and because there have been questions and confusion about our version numbering in the past, we would really like to choose a versioning scheme tat everyone could easily follow, and one that would allow us to communicate the fact that this next release is quite a large step from 0.5, but at the same time trying not to say that its absolutely bullet prooff.

I think we can say we have learnt some lessons from our time developing 0.6. Ones which we definitly must take in to consideration when planning for and numbering future releases. They are:

• We were perhaps too worried about releasing a new version with regressions from the previous release (e.g. worsening Internet Explorer support).
• Don't use cryptic letters in the version numbers (pre or preview is much better than p).
• Don't do a point release of a preview release (e.g. 0.6p3.2) it is just too long and confusing.
• Be clear about exactly what a release should contain and do not set goals that are unachievable at that point in time.

There are probably other things, but thats just a few of them.

Directly related to the version numbering, there have been two major issues since the preview releases. The first is the confusion with the actual letters and numbers. Other than the user simply being incorrect about the version, it also makes it hard if we are trying to solve bugs etc as the user is not clear about the version number. For 0.6p3 we have seen many different ways users write it. Some are:

• p6
• 6.3
• r6
• 0.6pl3.

The other major issue is the dreaded "1.0" issue. That is, when are we going to release 1.0.

A long time ago I guess we may have been striving towards this goal, hence the 0.5, 0.6 etc. Eventually we would reach 1.0.

However I think with the way the project has evolved (taking in to account future goals, finances, ability to perform automated testing etc), we are probably better off making releases that are quite stable, but make no promise or hint at where the project may go in the far future. In other words, we sort of want to get past the 1.0 thing, with out actually having to hit it. If we today released a 1.0 I'm very sure people would expect nothing more than perfection (at least in comparison with 0.5 etc).

So... where does that leave us?

Jamie and myself have come up with a few different options for the version numbers of the next and future releases. They are:

• Change nothing. The next release is 0.6 as we always promised. Advantage is that people will get what we advertized. Disadvantage is that going from 0.6p3.2 to 0.6 may seem backwards to some who don't get the p. Also 0.6 is possibly quite different to what we originally planned.
• Make the next release 0.7 (skipping 0.6). Advantage is we leave the whole 0.6 thing behind us. Disadvantage is that we are still creeping towards a possible 1.0, plus the 0 suggests an unfinnished product.
• Make the next release version 7. The 7 is completely arbitrary except for the fact that the next release could have been 0.7 (just drop the 0.). The advantage is we now can work with whole numbers, but we've skipped the 1.0. Disadvantage is that there could be a little confusion to do with why it went from 0.6 to version 7.
• The next release could be 2009.1. The 2009 is obviously the year, and the 1 means its the first release this year. The advantage is that we completely break away from an incrimental version and instead just base it on the point in time it was released.

With all these versioning schemes, we will still most likely release testing versions before the final release, though we will try and make these rather close in time to the final release. We will also use words like alpha, beta and rc, which are well-known accepted words for test versions.

We would like to gain feedback from people as to which versioning scheme they prefer, and why that versioning scheme works best. Which is the easiest one for you to understand? which one has a better ring to it? which one do you think NVDA would need in order to gain better footing in the industry? We much appreciate any feedback you can give. This includes even perhaps your ideas on a completely different versioning scheme we may not have thought of yet.

Please send your ideas to:  developers@nvda-project.org

Or talk about it on the email lists.