As you might have noticed, we have occasionally done pre-releases for our upcoming stable versions. If you have ever seen a file like vaadin-6.3.0.pre1.jar, that's the first pre-release of the past Vaadin 6.3. That's what we have had thus far: stable releases, pre-releases and, of course, the nightlies that published constantly, no matter what.
The pre-releases have been a combination of things: We have used them to show off some features that we felt were awesome and we wanted to show them to people, but we have also been using them as official release candidates. A pre-release was a little something we wanted to release before the stable version in general. We felt this being a bit too unstructured, though.
We have had this major.minor.maintenance.maturity version scheme going on, and we like it as it is. We're not going to change that. What we are going to change is the maturity part of it. Instead of the old pre, starting with Vaadin 6.7.0 Beta 1, we now use the following:
alpha: A snapshot among nightlies that is intended to highlight one or more features for interested developers so that we can receive feedback on that particular thing. We might remove or radically modify the feature after it has been released in an alpha. This means, any subsequent release (alpha or any other) may not include that feature at all. Subsequent alpha releases are very loosely coupled, and are not necessarily at all related featurewise.
beta: Once we are happy with the features planned for the release, we release our first beta: A feature-complete release of the upcoming version. The API may change a bit here and there, but no added functionality is to be expected since the prevous release. Looking at what the beta can do gives you an excellent overview of what the upcoming stable release will do. Subsequent beta releases build and improve upon the previous one. APIs and bugs are fixed and stability is increased.
rc: When we believe that we have fixed all notable issues, we'll release an rc, also known as "release candidate". This is our proposal of what could as well be called the stable version. Unless bugs are found in a while, we will re-release the latest release candidate as the stable version. Otherwise, we release a new rc with the reported bugs fixed. Subsequent release candidates only fix bugs that are found in previous release candidates.
stable: Once we have decided that a decent amount of time has passed since the last bug has been found and fixed in an rc, we will release the final version: The stable release. A stable release has no maturity indicator, only the major, minor and maintenance version numbers. Once a stable release is out, any subsequent bugfixes are published in a new release as an increase in the maintenance version number.
All of the maturity tags can be suffixed with a number, so for example "rc2" is the second release candidate of a certain version.
We hope this will make the development of Vaadin more clear for both us, the developers, and you, the users. We like a clear structure because it keeps our aims in check and our milestones foreseeable. We hope you can utilize the new structure by assessing whether you can start enjoying the latest and greatest features sooner than before.