Preparing for JIRA 7.5

This page covers changes in JIRA 7.5 that can affect add-on compatibility and functionality. This includes changes to the JIRA platform and the JIRA applications (JIRA Core, JIRA Software, JIRA Service Desk).

As a rule, Atlassian makes every effort to inform add-on developers of known API changes as far in advance as possible. Where possible, we attach release targets. Unless otherwise indicated, every change on this page is expected to be released with the first public release of the JIRA Server 7.5 products. We also make release milestones available prior to the release:

• For JIRA Server, the JIRA development team releases a number of EAP milestones prior to the final release, for customers and developers to keep abreast of upcoming changes. For more information on these releases, see JIRA EAP Releases.
• For JIRA Cloud, the JIRA team releases updates to the JIRA Cloud products on a weekly basis. Add-ons that integrate with the JIRA Cloud products via Atlassian Connect should use the JIRA REST API, which is subject to the Atlassian REST API Policy.

We will update this page as development progresses, so please stay tuned for more updates. We also recommend following the JIRA news on Atlassian Developers blog for important announcements and helpful articles.

Summary

The risk level indicates the level of certainty we have that things will break if you are in the "Affected" column and you don't make the necessary changes.

JIRA platform changes

All changes in JIRA platform are also relevant for JIRA Core, JIRA Software, and JIRA Service Desk.

New JDBC driver for Microsoft SQL Server

We've shipped a new driver for Microsoft SQL Server, which requires that you update the driver's URL in the dbconfig.xml file. In most cases, it's enough to run the JIRA configuration tool, which will update the URL automatically, but if you've customized the URL by adding some properties to it, you might need to make the changes manually. 

Running the JIRA configuration tool

If you never customized the JDBC URL, run the JIRA config tool to update it.

1. Go to <installation-directory>/bin, and run the config.bat/config.sh file.
2. Click Save. Your configuration will be updated.
3. Restart JIRA.

Updating the URL manually

If the configuration tool doesn't fix the error, update the URL manually.

1. Go to JIRA's home directory, and edit the dbconfig.xml file.
2. Adjust the value of the URL parameter to the following pattern:

1
2
jdbc:sqlserver://[serverName[\instanceName][:portNumber]][;property=value[;property=value]]

For details about the URL and its properties, see Building the connection URL.

When you start JIRA after the upgrade, you'll get an error message until you fix this issue.

Events for creating and deleting issue links

New events for creating and deleting issue links that might be used by plugin developers, or by users as webhooks in JIRA. The new events are IssueLinkCreatedEvent and IssueLinkDeletedEvent.

When creating webhooks, you can use the following events. The string in parentheses is the name of the webhookEvent in the response.

• create (issuelink_created)
• deleted (issuelink_deleted)

For more info about creating webhooks in JIRA, see Webhooks.

JIRA will fix corrupted indexes by itself

We've made this change already in 7.4.2, but we just wanted to make sure you know about it. JIRA now has an automatic recovery of corrupted indexes, which saves you a lot of manual work. However, the broken documents will be deleted from the indexes, and this might result in e.g. JQL not being able to find some issues. You can recognize that your indexes were being fixed by searching the atlassian-jira.log file for a line like this one:

1
2
2017-07-18 23:51:49,990 JIRA-Bootstrap ERROR      [c.a.jira.index.LuceneCorruptionChecker] Index '/jirahome/caches/indexes/issues' is broken: 2 bad segments.
    Performing healing the index. 2 documents will be lost

All deleted documents can be recreated by running a reindex in JIRA. For more details, see Lucene index corruption. 

REST API changes

We've also made some changes to our APIs:

• With GET /rest/agile/1.0/sprint/{sprintId}, you can now retrieve a new field called "goal", which shows a sprint's goal.
• With DELETE /rest/agile/1.0/sprint/{sprintId}, you can now delete not only sprints that haven't started yet, but also the completed ones.
• With PUT /rest/agile/1.0/sprint/{sprintId} and POST /rest/agile/1.0/sprint/{sprintId}, you can now use the new "goal" property to add a goal to a sprint.
• With POST /rest/agile/1.0/sprint/{sprintId}, you can update the "name" and "goal" properties for any completed sprint.

JIRA Core changes

No specific JIRA Core application changes.

JIRA Software changes

Improvements to sprints - rename and delete, add a sprint goal

We've introduced some new options that will help you manage your sprints. You can add a goal to a sprint to let your team know what you're aiming for, delete an obsolete sprint so that it doesn't affect your reports and future planning, or rename a sprint to something that better describes it.

For more info about this change, see JIRA Software 7.5 EAP release notes.

Epics and versions panels in the Kanban backlog

With JIRA 7.5, we're introducing two new panels in the Kanban backlog - versions and epics. They'll be enabled by default if you have previously enabled the Kanban backlog. The panels will help you refine your backlog, group your issues, and easily manage them by using versions and epics as filters. Because of this change, epics will no longer be displayed as cards on the board (like all other issues), but will be moved to the panel instead. If you don't like this change, you can disable the epics panel in Boards settings > Columns. 

For more info about this change, see JIRA Software 7.5 EAP release notes.

JIRA Service Desk changes

JIRA Service Desk has a number of elements of it's API which are currently defined as experimental  but that is about to change. With an upcoming release of JIRA Service Desk, a number of the methods in our API will be moving out of the experimental state and into standard API state. For most of these components the API will remain unchanged, but for some there will be adjustments which will represent a breaking change. 

What's Changing?

A number of components will have breaking changes. The changes are relatively minor and revolve around changes to IDs that will be returning integers rather than longs. This helps us to align with the values that we are currently storing in the database and will stop us having to do a lot of unnecessary type conversion in the future. 

The following will be changing in a forthcoming release (after JIRA 7.5.0):

What's deprecated? 

As well as the breaking changes listed above, we're also going to be deprecating a number of existing experimental API which will be removed in a future release. The following classes are being deprecated in preparation for removal:

• CreateInternalCommentParameters
• CreatePublicCommentParameters
• ServiceDeskCommentParameters
• ValidatedInternalCommentParameters
• ValidatedPublicCommentParameters
• RequestTypeUpdateParameters
• RequestTypeQueryParameters

In addition, the following methods are being deprecated. Some of these have equivalents which can be used, and where this is the case these are documented.