With the shift to subscriptions, one of our goals was to move away from the one major release per year model, focusing on continuously delivering value independently of versioning.
On changing to this model, a question that came up was, what exactly does a version number represent anymore? At the end of the day, what most of us as users care about when it comes to a new versions is:
- What does it provide me?
- How does it impact my work?
- Is it available to me?
But the question did give way to a few issues that we’ve been noticing for some time. In particular, given that our IDEs share common functionality through the IntelliJ Platform, many customers have questions regarding what feature or bug fix from one product is included in another. Whether customers are using multiple products or a single one, they should clearly see when a common platform functionality or fix will be available in the individual products.
The other problem, albeit mostly internal, is our own management of versioning given the number of products and releases we have per year, which we also want to increase.
Given these issues, we decided it might be a good time to try and address them.
Single versioning. Aligned releases.
We will be moving to a single versioning scheme for all our products under the JetBrains Toolbox. In particular this means all of our IDEs as well as our .NET tools.
In addition, we’re introducing a new versioning scheme which will follow the format
YYYY.R
where yyyy represents the year, and r the release within that year, obviously with the aim of having multiple releases per year. Each product will have its own full build number in the format yyyy.r.n.m*.
To give some examples, we might release 2016.2 for IntelliJ IDEA with a full build number of 2016.2.1.10 and subsequently release 2016.2 for WebStorm with a full build number of 2016.2.5.30. However both of them are part of the 2016.2 release.
As a consequence of these changes, all JetBrains Toolbox products currently available in Early Access will be released as version 2016.1.
This change doesn’t only bring a single new versioning scheme, but also aligned releases. This means that all our products under the JetBrains Toolbox will have the same number of releases throughout the year and will be released within a certain period of time from each other.
*While the first versioning scheme change will be 2016.1, the new build numbers will not reflect these changes until 2016.2 due to the necessary underlying work required.
What benefits does this provide?
We believe the proposed changes bring a few benefits both to you, our customers, as well as us.
To you as a customer
More frequent product updates
One of our goals in moving to subscriptions was to increase the number of releases per year, provide new functionality and improvements as they’re ready and not have to hold back for a major version release. This is that step.
Yearly based versioning
2016.2 has more semantic meaning as a version number than 11, because it indicates how recent the release is (in terms of year) and what release it is within the year, which also provides more visibility in our commitments.
Aligned versioning
If you use several products they will all have the same version number. Comparing WebStorm 2016.2 to IntelliJ IDEA 2016.2, if need be, is much easier than comparing WebStorm 11 to IntelliJ IDEA 16.
Availability
If you’re on an active subscription, the latest versions are always available so there is no change. In regard to which bug fix updates would be available to your Perpetual Fallback License, this information is always available under your JetBrains Account.
To us as JetBrains
More releases
We focus on providing value, be it features or bug fixes as and when they’re ready and not have to hold things back for major version numbers once per year. More frequently releases allow us to make them available sooner and get feedback faster.
Yearly based versioning
Given many of us cover multiple products, it will be much easier for collaboration and release planning to see how recent a product, feature or fix is by glancing at the version number. The new versioning will give us a much better mental model of time.
Aligned internal and public versioning
Given we’re sharing a common platform, for us internally it is much easier if all our tools follow a single versioning scheme. The complete build numbers for each product is also aligned with our branches and then the actual build number which makes things easier. The only products that aren’t directly impacted by this are our .NET tools. However, given our new Project Rider .NET IDE does share the IntelliJ platform, and given that these products are also available under the JetBrains Toolbox, we thought it best to simplify and also follow the same model.
Obviously, our intention is not to compromise on quality and we will not move from Version Driven Development to Deadline Driven Development. Our goal is and always has been to provide value through innovation and quality. This is yet another step in that direction and we are committed to deliver.
