JetBrains Toolbox—Release and Versioning Changes

Posted on by Eugene Toporov

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.

Comments below can no longer be edited.

96 Responses to JetBrains Toolbox—Release and Versioning Changes

  1. bughunter says:

    March 9, 2016

    s/IDE’s/IDEs/g

    • Eugene Toporov says:

      March 9, 2016

      :thumbsup:

    • Blip says:

      March 10, 2016

      %s/IDE’s/IDEs/g

    • Mike says:

      March 11, 2016

      It is perfectly valid to put an ‘s after acronyms for pluralization. Style guides disagree on this point so for now either way is acceptable.

      • Martin says:

        March 17, 2016

        Mike, an apostrophe is that sign: ’

        And it’s just ugly to use them for plurals.

        • Eugene Toporov says:

          March 17, 2016

          We’ve had this conversation many times internally and decided we’ll stick to “IDEs”, but sometimes the IDE’s still happen 🙂

          • Kevin Kaland says:

            March 22, 2016

            So does this mean that PhpStorm 2016.2 will use the same IntelliJ Platform (including bug fixes) as IntelliJ IDEA Ultimate 2016.2?

            • Eugene Toporov says:

              March 22, 2016

              Yes, exactly

  2. Tropper says:

    March 9, 2016

    I like it. 🙂

  3. Richard osbaldeston says:

    March 9, 2016

    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:

      March 9, 2016

      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.

      • Richard osbaldeston says:

        March 9, 2016

        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?

      • Richard osbaldeston says:

        March 9, 2016

        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?

      • Nikita says:

        March 13, 2016

        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.

    • Maxim Mossienko says:

      March 9, 2016

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

      March 10, 2016

      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:

      March 11, 2016

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

  4. Richard osbaldeston says:

    March 9, 2016

    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:

      March 9, 2016

      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:

        March 9, 2016

        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:

        March 9, 2016

        You can use channels like Google Chrome.

  5. Alan says:

    March 9, 2016

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

    • Ilya says:

      March 9, 2016

      And then face Y2K100 problem? no thanks ))

    • Phil says:

      March 9, 2016

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

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

    • Mark says:

      March 9, 2016

      1999 called, they want their millennium bug back 😉

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

    • Rafał says:

      March 9, 2016

      +1
      drop the 20

      • Eugene Toporov says:

        March 9, 2016

        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:

      March 9, 2016

      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.

      • Mehdi says:

        March 11, 2016

        Can’t wait to try out IntelliJ IDEA 999.9

  6. Gauthier POGAM--LE MONTAGNER says:

    March 9, 2016

    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:

      March 9, 2016

      Thank you Gauthier. Glad you like the idea.

    • Tatiana Vasilyeva says:

      March 9, 2016

      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:

    March 9, 2016

    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:

      March 9, 2016

      That’s unlikely 🙂

    • bevis says:

      March 9, 2016

      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:

        March 10, 2016

        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:

          March 18, 2016

          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:

    March 9, 2016

    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:

      March 10, 2016

      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:

    March 9, 2016

    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:

      March 10, 2016

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

      • Keith Davis says:

        March 10, 2016

        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:

          March 10, 2016

          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:

            March 10, 2016

            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:

              March 10, 2016

              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:

                March 10, 2016

                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:

                March 14, 2016

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

      • Baron Roberts says:

        March 10, 2016

        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:

          March 10, 2016

          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:

            March 10, 2016

            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:

              March 10, 2016

              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:

                March 10, 2016

                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:

                March 10, 2016

                > 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:

    March 9, 2016

    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:

      March 10, 2016

      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:

        March 10, 2016

        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:

    March 9, 2016

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

    • Hadi Hariri says:

      March 10, 2016

      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. JetBrains Toolbox introduces new versioning and release changes - SD Times says:

    March 9, 2016

    […] said that given its IDEs share common functionality through the IntelliJ platform, many customers have […]

  13. Alex says:

    March 10, 2016

    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:

      March 10, 2016

      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:

        March 10, 2016

        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:

          March 10, 2016

          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:

    March 10, 2016

    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:

      March 10, 2016

      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:

        March 10, 2016

        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:

        March 11, 2016

        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:

          March 11, 2016

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

        • Maxim Mossienko says:

          March 14, 2016

          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:

    March 11, 2016

    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.

    • Eugene Toporov says:

      March 14, 2016

      Hi! Not sure I can explain what the problem is.
      It would be great if you can contact IntelliJ IDEA support with the issue.
      You can reach them at https://intellij-support.jetbrains.com

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

    March 11, 2016

    […] können User problemlos in ihrem JetBrains-Account überprüfen. Mehr Informationen dazu bietet der oben genannte Blogpost von Eugene […]

  17. TWiStErRob says:

    March 12, 2016

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

    • Eugene Toporov says:

      March 14, 2016

      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:

    March 12, 2016

    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:

    March 14, 2016

    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:

      March 14, 2016

      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. JetBrains ändert Versionierungsmodell: Willkommen IntelliJ IDEA 2016.1 und WebStorm 2016.1 - JAXenter says:

    March 15, 2016

    […] sei die Versionierungsnummer eher zweitrangig, so Eugene Toporov in einem offiziellen Statement. User würde vor allem interessieren, was die neue Version für den Nutzer bereithält, wie eine […]

  21. Roger Cotrina says:

    March 17, 2016

    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. IntelliJ IDEA 2016.1 Is Here | 神刀安全网 says:

    March 18, 2016

    […] we announced earlier, with this release we’re changing the versioning scheme and moving away from one […]

  23. Eli Bradley says:

    March 18, 2016

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

  24. Scott Glajch says:

    March 21, 2016

    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:

    March 22, 2016

    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:

    April 11, 2016

    When DataGrip 2016.1 will be released ?

    • Eugene Toporov says:

      April 15, 2016

      DataGrip should be available sometime next week.

  27. anon says:

    April 14, 2016

    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:

    April 14, 2016

    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:

    August 17, 2016

    Looking forward for new release
    Kunal

  30. Baron Roberts says:

    October 4, 2016

    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.

    • Eugene Toporov says:

      October 4, 2016

      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.

      • Baron Roberts says:

        October 4, 2016

        Thanks Eugene for the quick reply and clarification. This will help us with planning our rollouts of JetBrains products.