You might have noticed that we have recently made some new alpha and beta versions available for download without making any big announcements. This is part of our new strategy of every two weeks making new incremental releases of anything we have been working on.
Background
When we were building Vaadin 7.0, we made a new alpha release whenever we had one big chunk of functionality implemented. We did this to gather feedback and to give you a sneak peek at what we were up to. While we did get great feedback about how the designs and implementations of the new features could be improved, many of you also seemed troubled by the way we refactored or removed features that had been introduced in previous alpha releases.
With the smaller releases (compared to 7.0) we have been working on lately, we haven’t had that much need for such prereleases. There does still seem to be an interest in checking out unreleased features since nightly snapshot builds are being used to some degree, even though their use is not completely straightforward. One challenge is the potential stress factor from using anonymous builds where it is not very clear what changes from version to version. Another potential issue is the way automatic dependency management tools like Maven or Ivy will always be using the newest snapshot, even though you would actually want keep things slightly more stable on your end.
Alpha every two weeks
We have decided to address these issues by redefining how we release alpha and beta versions, while still sticking to the same idea about what can change between releases. The basic idea is that at the end of every two-week iteration, we release the result of that work as a regular non-snapshot build. For you, this means that there will be named releases (e.g. vaadin 7.3.0.alpha1) that have at least to some degree been verified to function properly, as opposed to the snapshot builds that are released as long as the code can be compiled. We still don’t want to add any additional overhead to our way of working. This means that we will not make grandiose announcements for each version, especially for alphas, or list exactly what has been changed since the previous release. We also make no guarantees about compatibility between alpha releases - it’s still basically a snapshot of work in progress, but it’s structured so that dependency management tool users can have control over when they switch to a different version.
Beta when all features are in place
Once we feel that all new functionality has been implemented, we switch to making beta releases instead. In these, we keep the release notes up to date, maintain a detailed list of changes and also try to preserve backwards compatibility with previous beta versions unless there’s some critical issue that require making breaking changes. With beta releases, it might not necessarily make sense to release every other week since we might be focusing on some other project while waiting for feedback from users.
In this fashion, we have already made silent releases of Vaadin 7.2.0 beta 1, TestBench 4.0.0 alpha 1 and Vaadin 7.3.0 alpha 1. We should also have at least Vaadin 7.4.0 alpha 1, TouchKit 4.0.0 beta 1, Vaadin Sass compiler 0.9.2 and Vaadin CDI 1.0.0 beta 1 queued for the end of the iteration that ends with this week. It should also be pointed out that when there are multiple alpha series for the same product, as with the simultaneous development for Vaadin 7.3 and 7.4, the alpha releases for the “higher” version does not necessarily contain everything included in the “lower” version. Today this means that alpha releases for 7.3.0 contain an initial version of the new Valo theme while 7.4 alphas only contain the current state of Grid but no sights of Valo. In this way, we keep the door open for e.g. changing the order in which we release two features if one of them is completed more quickly than expected while the other is delayed (although this does currently not seem to be the case with the current schedules for Valo and Grid).
With this change, we hope to make it easier for the community to participate more in the development of new features. It might also help us maintain focus when there’s always a release just around the corner that should really contain the feature that is currently in progress. Do you think this all makes sense? Would it make it more likely that you try out an upcoming release during the alpha phase?
Leif Åstrand is a jack of all trades in our R&D team. He knows a thing or two about how Vaadin, GWT and the internet works.