Less is More – Why Less Major Releases with Non-Breaking Updates Adding Features is a Good Thing


Answering to pressing requests from customers and partners, RAD Studio is moving this year from a 6 month release cycle with one main bug-fix update to a 1-year release cycle with multiple updates including fixes and new features. 
As we announced in our last published roadmap, https://community.embarcadero.com/article/news/16418-product-roadmap-august-2016, we are significantly slowing down the release cycle, going back to a more or less yearly major release for the product, from the faster cycle of recent years. There are many reasons for this change, but it mostly addresses complaints from customers (and tech partners, and component vendors).
The original requirement to release more often was driven by the fast-paced change in mobile operating system, compared to the Windows world — which is actually now moving much faster under Windows 10, but that’s a separate story. This requirement still applies, but it can be fulfilled in a different way.
This change in delivery cycle and model, in fact, is tied to another change, namely the fact that update subscription is now compulsory. I know you might not see the connection, but this gives us freedom to release new features and support new versions of operating system in updates, with no negative effect to the business financials. The only caveat, of course is maintaining the largest degree of binary compatibility with existing DCU files and packages. This might not be doable for a new operating system, but it is certainly doable for VCL and Windows, which is the platform the largest projects from our customers are on.
Berlin Update 1 was borderline, with some new features like native iOS grid added to the product, but most of the focus on fixing bugs. Berlin Update 2 has been the first this release in this new direction, with new VCL controls, new IDE designers, support for Desktop Bridge, and more.
It is true that delivering the same amount of features in a non-breaking update will require us some extra work, and in some cases (like Delphi language changes) it won’t even be doable. So we might have to delay some features, because of the technical limitations due of non-breaking updates. But we feel the benefit of a slower release cycle to the stability of RAD Studio and of our customer projects, and hope this will allow more customers to stay and migrate on the latest version sooner — with a good benefit in terms of their experience.
Needless to say your feedback is critical — and even more because this was mostly driven by customer feedback. Do you still feel the product can move in the right direction with this model? Do you feel your update subscription remains relevant? Will you be able to safe time and money while keeping up to date with RAD Studio? Or will you upgrade your projects every 2 or 3 years no matter what? Let us know.

Comments are closed.