Crucible 4.6 release notes
Linking reviews to multiple Jira issues
It’s a good practice to keep code changes small—raise a Jira issue, create a branch in Bitbucket, implement the changes, and finally review the code in Crucible. However, it’s not always the case. What if you’re working on a feature that requires changes in multiple components or services, stored in different source code repos? Or, you need to merge a bugfix branch into another release branch, and review the entire thing before merging?
Luckily, Crucible deals with such a scenario very well, as you can add changes from multiple sources of data - branches, commits, patches - into a single code review. But, what if each component has its own development cycle and a separate Jira project and issue key? What if the branch contains commits from many different bugfixes?
Until now, you could link a Crucible code review to only one Jira issue, and had to pick which is "the most important" one.
With Crucible 4.6, you can link a code review to any number of Jira issues, you no longer need to pick just one. Crucible will also show you a list of suggested issues for linking, based on the review content. The code review will be shown in Jira Development Panel under every linked issue, so you get a full traceability between all your issues and reviews.
We've also improved logging the time spent on code reviews. You can either choose a single issue to report the whole time, or split it between multiple linked issues. Crucible tracks the time spent on reviews automatically, but with version 4.6 you can also adjust the time manually, and enter a comment that will be reported to Jira when completing or closing the review.
Blame fallback cache
Remember the time when you wanted to see blame data for a file, and had to wait minutes until it finally appeared? Over and over again whenever you returned to the file?
Crucible calculates and persists blame data during repository indexing. However, if the indexing is not complete or if a system admin disabled storing of blame data, Crucible has to contact the source code management system (SCM) to fetch actual data. For slow repos, it might even take several minutes.
With Crucible 4.6, we’ve introduced an additional in-memory cache for this scenario. Thanks to it, you’ll need to wait only for the first blame request. When you go back to the file and click blame again, you’ll get an immediate response.
Mercurial 4.5 support
Crucible 4.6 supports Mercurial 4.5.
Git 2.16, 2.17, and 2.18 support
Crucible 4.6 supports three new major Git versions.
New Fisheye and Crucible logos with a brighter blue navigation bar, the latest PostgreSQL JDBC driver, and a number of security fixes are yet another reasons to upgrade to the latest version.
REST and Java APIs have been enhanced to handle multiple issues in a review. Also some deprecated methods have been removed, so your apps may require an update. Please read Crucible upgrade guide for more details.
This section will contain information about the Crucible 4.6 minor releases as they become available. These releases will be free to all customers with active Crucible software maintenance.
If you are upgrading from an earlier version of Crucible, please refer to the Crucible upgrade guide.
The issues listed below highlights some of the bugs resolved in Crucible 4.6.x.
8 October 2018 - Crucible 4.6.1
26 July 2018 - Crucible 4.6.0
Was this helpful?Yes Provide feedback about this article