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.

This entry was posted in News and tagged . Bookmark the permalink.

93 Responses to JetBrains Toolbox—Release and Versioning Changes

  1. bughunter says:

    s/IDE’s/IDEs/g

  2. Tropper says:

    I like it. :-)

  3. Richard osbaldeston says:

    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?

    • Eugene Toporov says:

      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.

    • Maxim Mossienko says:

      ‘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.

    • Erik I says:

      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.

    • Mike says:

      I use the EAP just fine for my daily work. It is pretty stable.

  4. Richard osbaldeston says:

    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?

    • Eugene Toporov says:

      The goal is to have incremental updates in 100% cases. We are working on making products updates, installation and rollback (if needed) as smooth as possible.

      • Gauthier POGAM--LE MONTAGNER says:

        Keeping a unique directory between release would be a good thing (ex: a “.CLion” folder instead of “.CLion10”, “.CLion15”, …).

        Rollbacking settings is already possible with “Settings Repository” plugin, but it doesn’t always work well between different IDEs.

      • Aldo Martinez says:

        You can use channels like Google Chrome.

  5. Alan says:

    Drop the *20* YY.MM.X reduces further noise.

    • Ilya says:

      And then face Y2K100 problem? no thanks ))

    • Phil says:

      Is there any non-trivial difference between these two examples?

      16.03.1 (YY.MM.X)
      16.1 (YY.X)

    • Mark says:

      1999 called, they want their millennium bug back 😉

      Given the current version numbering is also two digits, it might lead to confusion.

    • Rafał says:

      +1
      drop the 20

      • Eugene Toporov says:

        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.

    • Pep says:

      I would go for 16.1 instead of 2016.1 for the sake of simplicity. We’re approaching fast mid-century.

      In 2100, it can be 100.1. In 3000, if there’s any of us still programming, we’ll go back to the drawing board with regards to version numbering.

  6. Gauthier POGAM--LE MONTAGNER says:

    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.

    • Eugene Toporov says:

      Thank you Gauthier. Glad you like the idea.

    • Tatiana Vasilyeva says:

      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.

  7. Daiquiri says:

    What will happen: the need to release a new product sooner. Just like AV companies…

    In a February 2017: “jetbrains pycharm 2019 released”

    :-p

    • Eugene Toporov says:

      That’s unlikely :)

    • bevis says:

      Well, the first would be 2017.2.x.y then you’d have 2017.02.x+n.y+m. Its all detailed above. The idea is that major version is the first 2 (xxxx.x) not the first 1 any more.

      • Baron Roberts says:

        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”.

        • Charles Samborski says:

          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…)

  8. Dirk Nilius says:

    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.

    • Hadi Hariri says:

      In what sense possible competition? Right now, when we release RubyMine, the Ruby plugin is available the same day for IntelliJ IDEA. If anything this just makes the process even more clear.

  9. Keith Davis says:

    How will this affect the config folders (.WebIde110)? Will these be changing more often? It’s a pain for my team every time these change, I’d hate to have to do this more often.

    • Hadi Hariri says:

      Folders will change to new scheme but we’ll be providing a fluid migration for settings.

      • Keith Davis says:

        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?

        • Maxim Mossienko says:

          The folder is changed on every version as extra safety measure to have your older version of PS in properly working state.

          • Baron Roberts says:

            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.

            • Maxim Mossienko says:

              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.

              • Baron Roberts says:

                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?

              • Ilya says:

                While the migration works it leaves a lot of trash in the user home directory.

      • Baron Roberts says:

        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.

        • Maxim Mossienko says:

          Launch script can force IDEA to use custom configuration, see https://www.jetbrains.com/idea/help/project-and-ide-settings.html

          It would be great if you share details of your custom configuration changes for us to make settings import to be more convenient.

          • Baron Roberts says:

            Thanks Maxim for reminding me of this. While this addresses part of the problem, it does not address the concern over major feature changes (i.e. incompatible changes) being harder to detect.

            • Maxim Mossienko says:

              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.

              • Baron Roberts says:

                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?

              • Eugene Toporov says:

                > This means that potentially every release is what we would call a major release today.
                A kind of, yes. The difference is that the delta (number of changes) between releases will be smaller.

  10. Marcel says:

    Remembers me of Win 95, Win 98, Win 2k, Win 2003, … . If I need to know when something was released, I look it up in the release notes. I prefer the current versioning – http://semver.org/.

    • Hadi Hariri says:

      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.

      • Baron Roberts says:

        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.

  11. Ian Fortuna says:

    What does this mean for perpetual fallback licenses? What version will you end up with?

    • Hadi Hariri says:

      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.

  12. Pingback: JetBrains Toolbox introduces new versioning and release changes - SD Times

  13. Alex says:

    Hello,

    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.

    Alex

    • Eugene Toporov says:

      But “More frequent product updates” is the first thing that we mention. Releases coming out more often means “New features and timely bug fixes”, that you mention, are delivered to users faster.

      And yes, we do not hide that there is also benefits for us in the change.

      • Baron Roberts says:

        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.

        • Eugene Toporov says:

          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.

  14. Baron Roberts says:

    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.

    • Maxim Mossienko says:

      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.

      • Baron Roberts says:

        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.

      • Bogdan Calmac says:

        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.

        • Bogdan Calmac says:

          I meant “this does not address” instead of “this does not add”.

        • Maxim Mossienko says:

          We are working to detect and fix regressions as soon as possible.
          As to stable version concern, if there is no stable version then you, our users, will not use our IDEs.

  15. Coderec says:

    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.

  16. Pingback: JetBrains ändert Versionierungsmodell für JetBrains Toolbox

  17. TWiStErRob says:

    Will this also change those weird internal build numbers (14x) to something meaningful?

    • Eugene Toporov says:

      We plan to align build numbers with the versions starting with 2016.2 releases. They will be something like 2016.2.n.m

  18. Alvaro Gutierrez Romero says:

    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.

  19. Guy Marom says:

    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?

    Thanks

    • Eugene Toporov says:

      Guy, the plan is to do releases 2016.1 or 2016.2 within a certain period of time, not far from one another. So, IntelliJ IDEA will not lag behind WebStorm for more than several days, maybe a week.

  20. Pingback: JetBrains ändert Versionierungsmodell: Willkommen IntelliJ IDEA 2016.1 und WebStorm 2016.1 - JAXenter

  21. Roger Cotrina says:

    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.

  22. Pingback: IntelliJ IDEA 2016.1 Is Here | 神刀安全网

  23. Eli Bradley says:

    Does this mean that the plugin release schedules will finally be aligned with their corresponding lightweight IDEs?

  24. Scott Glajch says:

    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.

    It is funny to see “.IntelliJIdea2016.1” for settings folder :-)

  25. rick says:

    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.

  26. Thibault M. says:

    When DataGrip 2016.1 will be released ?

  27. anon says:

    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.

  28. Baron Roberts says:

    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.

  29. kunal says:

    Looking forward for new release
    Kunal

Leave a Reply

Your email address will not be published. Required fields are marked *