Upsource 2.0 Hits Final Release

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.

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

12 Responses to Upsource 2.0 Hits Final Release

  1. Florian says:

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

    • arokhin says:

      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:

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

    • arokhin says:

      Please use this license:

      Name: Upsource 2.0 Free 10 Users Pack
      Key: bec61c738621fb9bee6dfc650e0b23012d935564a6169ec44d45eb40fb07a52325f441c89c57d9
      23ca83fa1b1a4d766655f90a365c1de49f1ed20292b2f0c72ed29abd20c8aa5f160eb5eba32f5d
      5b46523eea35674f07042a10cc6112e9fecc020c50890b51f6d374e36fb60cc37427daf09b238c
      09a88e09de8b9cfbefc254

  3. Peter says:

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

  4. Krzysztof Miksa says:

    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:

      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:

    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:

      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 https://youtrack.jetbrains.com/issue/UP-4188 that you might want to upvote and watch.

      • Yury V. Zaytsev says:

        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.

        –Yury.

        • arokhin says:

          Yury,

          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.

Leave a Reply

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