For us, Release 3.0 is a major achievement and a significant success. We managed to fix multiple kids' diseases that were hidden in the code, we reworked problematic parts, automated many steps, revised the whole project infrastructure including CI, web site, release procedure... Especially the later one still needs some tweaking as explained later.
You can have a look on the list of closed issues for this release. The user experience should be now better. We prepared automated scenario migration to the last version (running this is however still little bit clumsy), we fixed all the issues with reporting (early or late results were not recorded), we did some PoC with Google charts output (and decided to solve that differently in version 4.0), we have some progress on the tooling (Eclipse plugin is almost done), we extended our tests to the level of advanced integration testing (running in-container testing of JMS sender for instance, special credit goes to an university student who implemented it), and many other changes that might be hardly visible from the outside but were important inside.
There is still one component in PerfCake that is not easy to extend or to implement on your own - the generators. They do not have an interface but an abstract parent class. This is something we would like to change for programmers' convenience.
From the users perspective, our priority is the tooling, documentation, migration from previous versions (and possibly migration from other tools), execution in a clustered environment, ability to directly represent results graphically (using charts).
We also have a plan to finally provide another way to specify the scenario - a DSL language. This feature is almost in a technical preview state.
So, what went wrong during the release and why we ended up with version 3.2? The reason is quite silly and it is a lesson learned for the next release. During the release procedure, we prepare everything on Github first. The master branch has a new version and the devel branch is set to continue on the next release. Then we prepare the artifacts and upload them to Sonatype for them to appear in the public Maven repository. Then our Continuous Integration environment automatically consumes the sources from master and runs all the tests. It also creates downloadable artifacts for automatic web pages refresh.
So after releasing version 3.0, we realized that the tests do not work well in the CI environment. We decided this must be caused by a different environment setup, implemented a fix, executed tests locally and released version 3.1.
But this did not help! Still the same errors appeared in the CI. After a more thorough inspection we realized that there is a problem with the javadoc Maven plugin (the recent version was backward incompatible). So we eventually fixed that and released version 3.2.
Next time, we must run our CI stuff before the upload to Sonatype.
And one more thing - there will be another release, version 3.3, shortly before GeeCON in Prague 2014. We want to present some cool new features there during the Lightning talks.