JetBrains Toolbox—Release and Versioning Changes

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.

I’m more concerned about how multiple releases per year effect ongoing support and my perpetual fallback licence.

Already with 15 issues we see in the forums ‘try 16 eap’ as a solution like I can afford to use a half-finished IDE in my day job. But it seems support for 15.x will dry up pretty quickly so more releases really means more forced marches for subscribers? stability is far more important to me than new features and toolkit support I’ll probably never use.

It wasn’t clear when subscriptions were launched that the fallback licence concession would be pointless if more releases were made in one annual subscription. I know I can extend my subscription by another year when 16 comes out in the next few weeks. But how many times I year are we expected to buy another 12m just to keep that previous version safety net? Or will a new fallback licence cover the whole 2016.x range or something? this isn’t clear to me.

I already struggle to work out from youtrack tickets what release a fix should have appeared in. How exactly does yet another versioning system help?

Thank you Richard.
Stability is exactly what we’re after with more releases. It is hard to predict how long each release is supported but all critical fixes will surely be included in both current and previous branches (releases).
The fallback will cover 2016.x release and all its updates. 2016.x+1 is not covered automatically.
With shared codebase and several YouTrack projects I understand it is not always easy to understand the expected fix version, etc. But I believe information in our tracker will become more structured and clear with the complete transition to new versions for all products.

So If switched to a subscription at end of January I’d effectively have a 2016.1 fallback? (my fallback is listed as just 15).
Will 16 now become 2016.1? or I’d have to but another 12m ontop of my till 2018 subs to switch to the new scheme?

My firm has started asking potential hires to explain the JetBrains licensing model early in the interview process. Really cuts down the time we waste with unqualified candidates. Of course, we haven’t actually completed a hire in more than 6 months…

Is there not some way to create a hook on releases/merges to annotate fixed tickets with the release version they went into and take the internal fixed in (ci?) build no. bit out of the equation (at least less relevant to public). Inc. any backports to previous releases?

You know, honestly, the new perpetual fallback license is increasingly looking like a mere token gesture to satisfy an imaginary checkbox.

> It is hard to predict how long each release is supported but all critical fixes will surely be included in both current and previous branches (releases).

When I bought IntelliJ 15, I knew that I’m getting a perpetual license to at least a year of bugfixes and minor improvements. All of them, not just critical ones that make the app crash and burn.

With your new model, and especially now with these incremental upgrades, all I’m getting is a license for a single snapshot of
an app that is perpetually in beta. This is a marked downgrade for me. None of the bugs I care about are marked as “Critical” in YouTrack.

At this point I’m seriously considering just using EAPs instead of getting the new subscription.

‘Try 16 eap’ is not a solution but request for testing, not all problems can be reproduced by us in our environment. Note that most of bugfixes are done in trunk and can be backported once they become stable and it is *safe* to backport them.

This (reporting a bug in the paid version only to be told to upgrade to next paid version) is what broke it for me when I bought a version a couple of years ago.

I guess it was just a mistake in helpdesk but since then I have almost fallen in live with Netbeans and while I still try IntelliJ IDEA once or twice a year and tell others it is great this exact point is where I jumped off.

That said, perpetual fallback license is one really brilliant idea, and a way forward that gives safety for end users as well as providing the benefits of a subscription model to both parties.

Also will these full releases use the incremental update or the PITA full installer, needing settings migration, re-generating my licence keys, rework all my menu and icon shortcuts and painfully slow IDE full reindexing on on my projects?

This was discussed but while 16 for IntelliJ IDEA can be thought as current year, 8 (for RubyMine) or 11 (for WebStorm) are different. And we think a clear year reference is better than just number which seems random if you do not think about it.

Good idea. Today, all products have there own version number, but it’s not really clear nor easy to follow. “What was the last version of WebStorm ? 11 ? But my IntelliJ is 16…”.

Moreover, this new release scheme is a good thing : since the release of JetBrains Toolbox, more EAP has been opened (even if no news concerning the RubyMine’ EAP), and as an user of EAPs, I really appreciate it as every week, it provide new features.

RubyMine has been updated every week since EAP was open on January 14. During this EAP we have been mostly focused on polishing rather than new features, so blog posts were not there every week. Please choose “Early Access Program” in “Automatically check updates for” dropdown (Preferences | Appearance & Behaviour | System Settings | Updates) to get notifications about new EAP builds.

It is hard for me to reconcile the amount of discussion and clarification that this new scheme requires with the value it provides over semver. Most developers understand semver or at a minimum know to take major version increments very seriously. I am not sure what to make out of something like 2016.2 being called a “major version”.

I agree with you. I really like the standardization across the various IDEs but it bothers me that the major version number will no longer be this clear. Maybe something like “2016a”, “2016b”, “2016c” instead of “2016.1”, “2016.2” etc. would have helped in regard to semver. (Though, using letters usually denotes non-major version too…)

Does this also brings a possible competition between the IDE and plugin releases? At the moment there is a asynchronous release cycle (e.g. of Rubymine and the Ruby plugin) so it’s hard to find out if certain features of a RM release are included in a plugin release.

That does not suffice. We copy custom templates over and some of us (like myself) store our config folder (most of it) in Git, in order to maintain the exact same config on multiple machines (and because we’ve lost config changes with PS before). Great, more work for us. Why the need to change the folder on every version?

This seems like an awkward way to address backwards compatibility issues. Even if this process is made “transparent” by some automated mechanism within the IDE, that comes too late for the kind of pre-provisioning and pre-configuration that we (and it sounds like Keith and others) perform.

New IDE version suggests automatic import settings from old one on the first start. Please be more specific when it doesn’t work right.

New config folder for new version is needed to avoid forward compatibility issues with older version for which some customer might have perpetual license. Consider case he/she decides to stop using newer IDE version and rollback to old one.

Since a configuration folder can be specified in the idea properties file, will it be safe to specify our own? By “safe”, I mean how long before new versions of the IDE cannot read the existing version. Also, in the case of a custom configuration directory, will the configuration upgrade machinery in the IDE perform upgrades to the same custom folder?

At my company we perform a significant amount of configuration of IDEA through manipulation of the XML configuration file. This is automated through a launch script so that it is performed when IDEA is started. The frequently changing configuration directory name will make this even more difficult than it is today. In addition, there have been problems in the past with migrating configurations between major versions (i.e. major functionality changes). We have been able to advise our teams when to migrate preferences and when to reset them based on the major version number of the release. This new scheme will make it much harder to determine and prepare for these major changes.

Our current expectation is to have same or less amount of major incompatible changes for configuration across year of releases. In other words, things are expected not break more often and there is another config directory as last safety measure.

It would be really great if you provide specific examples of last major configuration changes that affected your company.

If I understand the new scheme and what you are saying, potentially incompatible changes can come out in any release during the year. This means that potentially every release is what we would call a major release today. Is that correct?

Semver doesn’t really make sense for end-user applications as much. In regard to the year, as indicated in the blog post, we feel aligning releases with years makes things somewhat easier than random version numbers. The only key thing here is that we keep them aligned and that’s our intention.

Semver has been very useful to us in determining the impact of a release. It provides us with an indicator as to how much qualification we must perform before releasing the new version of the IDE to our 1000+ engineering community. It is also a guide for our plugin developers as to when they need to plan for possible changes and release of their plugins.

It doesn’t impact perpetual in any way. You’d still get the version that was available at the time your 1 year subscription started. The exact version will always be available to you via your JetBrains Account.

I am under impression that you are trying to solve a problem that does not even exist. A simple timeline table with all products listed in it will answer the question- what was released and when.
I don’t buy an argument that the new ver scheme will bring value to customers. New features and timely bug fixes do.
Also, there is nothing wrong with existing “independent” releases. It seems to me that you try to make engineers work to one common schedule- good luck. Releases of each product will be rushed and we will see an avalanche of bug fixes for bug fixes soon.

Can you help me understand how the new scheme accelerates bug fixes as compared to the existing scheme. I assume the gating factor for bug fixes is the time to QA the changes. That seems independent of versioning schemes.

Versioning scheme is the facade for the internal changes, e.g. release cycle change.
Let’s take IntelliJ platform products as an example.
We have a platform which is the base for many products. There is development (new features, fixes) in the platform and also in the product-specific code. To release a product the platform must be stable. We currently plan to make the platform stable more often than before throughout the year so products can make releases on a more recent version of the platform and deliver features and fixes both from product specific code and from the platform.

Thank you for presenting your versioning plans being open to comments. Similar to many others who have responded, I am finding it hard to find the value in this change but can find a large number of negative issues it will raise for our deployment of IntelliJ IDEA in our company. These issues include:

– Losing the ability to easily determine major releases from bug fix releases. At my company we pre-provision and pre-configure IDEA for our 1000+ engineers who use the IDE. We rely on the major/minor release pattern to determine the amount of testing we must perform and to alert us to possible changes that will adversely effect our customizations.

– The need for more frequent migration of the per-user configuration directory, will lead to bloat in the user’s home directory. You must leave the old directory around in case the user needs to downgrade, which becomes a more likely scenario since it will be harder for users to assess whether major changes have been made (plugin incompatibilities typically happen at major release boundaries).

– I am very concerned that these changes will make it harder for plugin developers to target their plugins to a particular major release. More importantly, it could make it more difficult for plugin developers to determine when they must update their plugins for major changes that effect them.

In general, we have never needed parity between versions of the various JetBrains IDEs (and we use at least five or them). The pace of innovation in the IDEs has been fine for our 1000+ engineers and we have found great value in using the yearly major version upgrades to help guide our testing and adoption of new versions. I urge JetBrains to very carefully consider the negative impact this new scheme will have on its users and reconsider the approach.

Thank you for your feedback!
With our new versioning your company can still have yearly update cycle for IntelliJ IDEA. The decision of when to upgrade is in your hands based on functionality we deliver in particular versions.

We strive to provide updates as soon as they are released by JetBrains. The point is that the new scheme will make this more difficult because it will be less clear whether a release has more impacting changes. In addition, having the per-user configuration directory name change between ever release will negatively impact the automated configuration mechanism we have developed to ensure a consistent IDE provisioning and configuration across our 1000+ engineers.

This does not add the stability concern though. With a much higher release cycle that brings in both features and new fixes, there will never be a stable version. Version 2016 is almost released and some regressions introduced in Version 15 that I care about have not been fixed.

Hello,
I’m really wondering what on earth does IntelliJ Idea 15 and 16 do when its starting and debugging?
As long as the network is connected, it will hang on for nearly 1 minute before I can see the startup window or the debugger really stops at the breakpoint.
For startup, before the log is wrote down, after the system log shows it is started, there may be 1 minute hanging.
This is really confuse me, btw, the operation system is OS X EICapitan 10.11.3.

I like the idea of the new versioning schema.
At the end, if anyone has any problem with it, you can take the R number (YYYY.R) as today major release.
For me we will gain in clarity when looking at the different products, and for sure that JetBrains will gain in efficiency developing their products with the same code base.

Does this mean IDEA 2016.2 and WebStorm 2016.2 will be aligned in their features as well? Or is IDEA still gonna lag behind WebStorm?
If lagging – then is it gonna be now one release behind? Meaning IDEA 2016.3 will include all features of WebStorm 2016.2?

As a few others have mentioned, when someone bought a perpetual license, one expected the fallback version to last for at least one year worth of bug fixes and feature work. For example, I have 15 as a fallback and expected to keep update to date at least until 16 was released later during the year (October/November). Now that you have released 2016 so soon you are also making perpetual licenses become more obsolete sooner. Not cool.

I’m not a fan of the “Date as verison number” trend. At the end of the day the biggest piece of data that matters when you see a new version is “how much changed”. And allowing developers, regardless of how often the releases happen, to tell you this via major/minor version is important.

Wow it just gets more confusing. I already don’t like the “fallback complexity license”, and now this makes it worse. Someone buying in December is going to be screwed just because of an artificial major revision bump.

A licensing model that requires diagrams is not one I enjoy.

How about you just give us a year license, we get any update we want, and when it runs out you stick to that update. Figure out how much that costs and be done with it.

Dumb marketing bullshit that causes more trouble with no real benefit other than pushing more releases you can support for 30 days then abandon. Go back to semver like when resharper licenses made sense.

I find it confusing that you not only abandoned semantic versioning, you now have two part and three part versioning. Many organizations, especially larger development shops, typically have scripts that manage tooling deployment. This new versioning scheme complicates those scripts. It would have been cleaner and easier for us to have 2016.1.0 followed by 2016.1.1 for the bug fix release, and then 2016.2.0 for the next feature release.

Sometime this fall you will be releasing IntelliJ IDEA 2016.3. How are you planning to handle minor upgrades to that version in 2017. During 2016 you have treated 2016.n as a major release and 2016.n.m as a minor release. How is that going to work in 2017 when you want to want to do a minor upgrade to 2016.3? Will it be called 2017.3.1, 2016.3.1, or something else? If you were following you original semantic versioning (i.e. 15.n.m, 16.n.m) this would not be an issue. Having tied the version number to a year place appears to have placed an arbitrary restriction on your numbering.

Baron,
I do not see a problem, it works exactly as with numeric versions…
If we need to release an update to 2016.3 in 2017 we’ll do it and it will be called 2016.3.x. It will also be available to everyone who has 2016.3 as a permanent fallback license.