Fast CMS release cycles for the win
Work on large releases ties down resources and slows down innovation, especially if you plan to keep things backwards compatible. WordPress, for example, has traditionally been very good at both backwards compatibility and a rapid release cycle.
WordPress is very well managed as a product. They've risen to be the most popular content management system on the web by compact releases which continuously evolve the user experience while keeping backwards compatibility intact.
WordPress has kept the pace steadily for years, but they've not done fundamental changes. This shows in places and remains to be seen how long this approach will be valid.
Drupal has traditionally had a backwards breaking releases. The current ongoing work on Drupal 8 has been a humongous undertaking. I will argue that Drupal 8 should have been limited in scope and we should now be looking forward to the release of Drupal 10 with the feature set of the Drupal 8 we will get soon. But developers are people and are (feature) greedy. The product looks like a major technical leap over version 7, though.
eZ Publish is a very feature rich application with a great track record in Backwards Compatibility (BC). In 2012 eZ Systems announced that eZ Publish 5 will use the Symfony2 Full Stack Framework and since that product has been gradually rewritten to rid the old code application code. While there was a constant release stream, this lead to feature stagnation and a somewhat confusing dual kernel architecture for new users.
From leaps to baby steps
Both Drupal and eZ Platform (Publish) have now cleared most of the hurdles of their latest large iterations and are now set to take the path of WordPress in smaller releases. Drupal 8 will use Semantic Versioning and eZ Platform will follow a 2 month release cycle:
Fast Track Releases (FTR) come out every two months, and each release is supported until the next one is out, in other words it follows a “rolling release” model. We aim to do micro updates to these in between for blocker and critical severity issues, while other issues are rolled into the next FTR release.
This should allow the teams to take on smaller pieces of functionality. Gradually moving the product forward on the stable foundation of Modern PHP. Both systems can experiment more, yet keeping their core APIs stable for developers to build upon - similar to Symfony Release Process.
Large breaking changes for software this mature and widely used have become unacceptable in todays environment. Thankfully, the PHP ecosystem has grown up and effective reuse of software components across projects is now feasible.
Ideally your core developers should be on the same level as module / extension / plugin developers. That way you'll have to learn to rely on your Public APIs. The first test for this for the eZ Platform is integrating with eZ Studio, a closed source software suite building ontop of the Open Source eZ Platform.
These changes won't eradicate version numbers and automagically turn your web applications / sites to continuously evolving platforms like Demandware or Enonic, as most projects built with Drupal or eZ Platform require extensive tailoring. But if you plan to use these tools to provide a service similar to WordPress.com, then this is a great step forward.
Ship often. Ship less, but better.