Upsource 2.0 Hits Final Release

Jura Gorohovsky

This is the day when we are closing the Early Access Program and launching the Final Release of the latest Upsource: please download and try Upsource 2.0 RTM.

This is a free upgrade for all existing commercial customers, and even if you’re not using Upsource so far, remember that a 10-user plan is free of charge.

As a recap, Upsource 2.0:

  • Introduces an IDE plug-in for code review that works in IntelliJ IDEA, WebStorm, Android Studio and other IntelliJ-based IDEs
  • Supports SVN branches, as well as Git and Mercurial tags
  • Extends Java code analysis and navigation to Gradle-based projects
  • Compares Java code usages across revisions
  • Streamlines the code review process with suggested reviewers and revision picker, among other ways
  • Learns to provide JavaScript navigation and usage search in HTML/CSS/JavaScript projects (treat this as an experimental feature though)

You can learn more about new features and improvements in Upsource 2.0. Alternatively, here’s a video that sums up most changes in less than 2 minutes:

Please note that extended issue tracker integration announced during EAP has been postponed and is most likely to be released in a minor update next month.

Download Upsource 2.0, follow Upsource development on Twitter, and get in touch with the team if you have any feedback.

Comments below can no longer be edited.

12 Responses to Upsource 2.0 Hits Final Release

  1. Florian says:

    May 21, 2015

    Will it run on Windows properly now or is it still bugged?

    • arokhin says:

      June 2, 2015

      Sorry for the delayed response, have been experiencing some issues with spam filtering on the blog.

      Yes, Upsource 2.0 will run on Windows with no issues.

  2. kik0220 says:

    May 21, 2015

    Can I switch 2.0 EAP build to 2.0 RTM ?
    RTM displayed “Invalid License”.

    • arokhin says:

      June 2, 2015

      Please use this license:

      Name: Upsource 2.0 Free 10 Users Pack
      Key: bec61c738621fb9bee6dfc650e0b23012d935564a6169ec44d45eb40fb07a52325f441c89c57d9

  3. Peter says:

    May 21, 2015

    Is support for C# / .NET on the roadmap?

  4. Krzysztof Miksa says:

    May 21, 2015

    Upsource 2.0 look very nice. It will be great to integrate also VCS repositories into Upsource. Do you plan such feature in future?

    • Artem says:

      June 2, 2015

      Yes, it’s one of the major features we are going to introduce in on of the next releases. Probably at the end of this year or beginning of 2016.

  5. Yury V. Zaytsev says:

    May 28, 2015

    What is supposed to happen in Upsource 2.0 when one force-pushes the git branch that is currently being reviewed, e.g. after a substantial rebase as requested by the reviewers?

    In Gerrit this creates a new version of the patchset (v2, v3, etc.) which is attached to the same review. The old patchset is kept as v1 along with all comments that pertained to it. Reviewers can now see the difference between the patchsets to check if their concerns have been addressed, and also between the patchset and the current master. On Github it works in a similar way with pull requests…

    So far I wasn’t able to find the answer in the documentation.

    • Artem says:

      June 2, 2015

      You know, force-push is not one of the best-practices and for say is prohibited on the server side here in JetBrains Upsource team. We are not sure yet how and if force-push support should be implemented within the product. Anyway thanks for providing comparison with Gerrit and GitHub, it may helps us to set right priorities and consider adding this for the future versions.

      In the current version, after force-pushing a branch that is currently under review, Upsource loses all review comments.

      I’ve created corresponding feature request that you might want to upvote and watch.

      • Yury V. Zaytsev says:

        June 2, 2015

        Hi Artem,

        Thanks for the answer! Could you please explain to me what do you mean by force-push not being a “best practice”?

        Clearly, force-pushing of any public branches is a very bad idea, but there is nothing inherently wrong about force-pushing developer feature branches, especially if the previous heads are archived like on Github; it all depends on your development workflow. Using the same kind of logic, you may declare rebase evil, while arguably it is one essential and most used features of git.

        If you use topic branches workflow, and the development of your topic branch is taking a non-negligible amount of time, while the project itself is rather active, you’ll inevitably have to track the master branch. There are two ways to do this: merge from master to the topic branch, or rebase the topic branch regularly on top of master. Neither of those ways is a “best practice”, they are simply different, and each has its own advantages and disadvantages, which the developers need to understand.

        The disadvantage of reverse merging is that over time your feature branch accumulates a huge amount of cruft (spurious merges), which makes the navigation of the history and reviewing of the patch sequence difficult and confusing.

        The disadvantage of rebasing is that it makes it difficult to automatically bisect the bugs caused by bad conflict resolution during the development of the feature branch. However, arguably, it mostly happens in practice because you badly scoped your feature branch, your code has severe coupling issues, and so on, so bugs obscured by rebase are just indicators of much more general problems with your project.

        At the same time, by iteratively refining your patchset through rebases by taking into account reviewers comments leads to very clean and grokable patch series that are a pleasure to explore and review (if you have been involved in Linux kernel development, you’ll see what I mean).

        So it really a matter of what works for your developer team, how your project is set up, etc. In this sense, systems like Gerrit support both possible workflows, and do it very well. Let me know if you need further examples, explanations, etc. and I will try to help.


        • arokhin says:

          June 2, 2015


          One can argue about best practices, but you are right that there are different scenarios in different teams. That is why I have created a feature request for your scenario in our issue tracker. Feel free to vote up, watch and comment.


Subscribe for updates