This had some advantages, but also some drawbacks.

* "Tunneling effect": some components with great improvments could be released earlier for better user benefit.
* Confusion about what actually IS Petals ESB get: what we called the ESB was actually its core, or skeleton, but it wasn't very useful before you take some components to use with it.
* Difficulty of "assembling" your dream team: thanks to our great variety of components, each one having its own roadmap and lifecycle, it could be difficult at times for newcomers to pick up the best component version for a given container.

Things thus changed with the new 4.x branch onwards.
* Container version number and distribution number is now decorrelated.
* Each component is released following its own lifecycle, without waiting for the others.
* We aim to publish at least twice a year a bundle including the container and recommanded components to use with it. This is what we now call Petals ESB.
* For expert users, each component and container is still downloadable separately in any version.

Petals ESB 4.0 was released in 2012 February, as the first instance of new policy: it brought a nicely amped kernel and wanted features in some of our most used components ([read full release note|http://www.petalslink.com/en/news/latest/new-release-petals-esb-40-distribution]

Petals ESB 4.1.0 was released mid-2012, focused on performances improvements in critical situations and command-line driven management ([release note|http://www.petalslink.com/en/news/latest/new-release-petals-esb-41]).

Since then, a few maintenance releases have been published on indivudual components. Most of all, a huge work of code rewriting has been done on major parts of the ESB, to set up a hard base for upcoming features, and strenghen performances in large-scale situations.
Its results will be available shortly, as Petals ESB 4.2 is in the starting blocks...