Documentation for JIRA 4.4. Documentation for other versions of JIRA is available too.
Once you have upgraded to JIRA 3.7, downgrading to a previous version is not a straightforward task and is not recommended.
This page lists a few things to be aware of when upgrading from previous releases of JIRA to JIRA 3.7. To perform the actual upgrade, see the upgrade documentation.
Note: If you are upgrading from a pre-3.6.5 release, please also refer to the relevant JIRA 3.x Upgrade Guides.
Please note that some new functionality will not be available if you are running JIRA on WebLogic or Orion. The List All Filtersportlet will not be able to fetch the issue counts for each issue. The new 'Charting' View will also be unavailable. The support for WebLogic and Orion will be added in JIRA 3.7.1.
Due to the upgrade of HSQLDB, and to improve compatibility with Firebird and Frontbase, various database tables and columns have been renamed. For more details on the changes please see the JIRA 3.7 Database Schema Changes document.
Therefore, the easiest way to upgrade to JIRA 3.7 is to follow the Upgrading JIRA safely instructions.
If in the past, instead of performing an XML backup and restore, you have been upgrading by "pointing" new version of JIRA at an old database, this is still possible, however the procedure is more complicated. You will need to use SQL scripts to perform database schema changes. For more information please see the SQL Scripts for 3.6.x to 3.7 schema upgrade document.
If you are using HSQLDB with JIRA, you must follow Upgrading JIRA safely instructions (i.e. perform a full XML backup and restore from XML), as simply copying the .script
file will not work. The format of the .script
file has changed between the HSQLDB versions, and therefore, copying the .script
file will result in the following error on startup.
In order for plugins, customfields and portlets to function better outside of a web-context (e.g.: displaying a customfield in an e-mail), all direct references to the HttpServletRequest have been replaced by a VelocityRequestContext. If you have deployed your own plugins, customfields or portlets that use the HttpServletRequest directly (i.e.: any references to ${req
}) than they should be changed to use the new ${requestContext
} object. The ${requestContext
} is an implementation of the VelocityRequestContext
interface.
Currently the ${requestContext
} supports the following properties:
${requestContext.baseUrl
} - Returns the same as HttpServletRequest.getContextPath() or the base URL configured in your JIRA instance if no HttpServletRequest is available${requestContext.requestParameters
} - Returns an implementation of RequestContextParameterHolder
or null if no HttpServletRequest is available${requestContext.requestParameters.servletPath
} - Returns the same as HttpServletRequest.getServletPath()${requestContext.requestParameters.requestURL
} - Returns the same as HttpServletRequest.getRequestURL()${requestContext.requestParameters.queryString
} - Returns the same as HttpServletRequest.getQueryString()In JIRA 3.7 Database Integrity Checks (available from the Administration section) have been re-written to run as multiple transactions, which increased the throughput of the system while the checks are running. In large JIRA 3.6 (and earlier) installations, integrity checks could cause database lock escalation and stop users from performing operations (e.g. viewing issues).
Please note, that due to the change, each integrity check became about 10% slower.
As integrity checks are quite database intensive operations, it is still recommended to run them during off-peak hours (i.e. while the system is not under heavy load).
We have changed the AddComment and TransitionWorkflow jelly tag attribute that specifies the group visibility level from 'commentLevel' to be 'groupLevel'. If you have existing jelly tags that use this attribute it will need to change. This was done so that we could introduce the 'roleLevel' attribute which allows you to specify a project role based visibility. Only one of the two attributes can be specified at a time.
The RemoteComment object and therefore the remote SOAP/RPC api has changes to almost all properties. The 'roleLevel' attribute was added and the following attributes have changed:
The ActionManager
interface has been removed and its functionality has been delegated to new interfaces. For details please refer to ActionManager Removed documentation
com.atlassian.jira.action.action.WorklogCreate
if you were using this class in a plugin or custom code you will now need to use the com.atlassian.jira.issue.worklog.WorklogManager
this now has method calls to return worklogs for a given user+issue and also create worklog entries.com.atlassian.jira.action.action.ActionCreate
if you were using this class to create comments you will need to modify your code to use one of the create methods on the com.atlassian.jira.bc.issue.comment.CommentServiceWe have modified the com.atlassian.jira.event.issue.IssueEvent
class to no longer use GenericValues. The GenericValue representing the comment is replaced by com.atlassian.jira.issue.comments.Comment
class and the GenericValue representing the worklog is replaced by com.atlassian.jira.issue.worklog.Worklog
class. If you have a custom listener in a previous version of JIRA this will need to be updated to use the newer IssueEvent class and com.atlassian.jira.event.issue.IssueEventDispatcher.dispatchEvent(...)
methods.
By popular request, the XML filename (that is, the default filename when you choose to save the XML view in the Issue Navigator) has been changed from issuenavigator.jspa
to SearchRequest.xml
. Should you have any external systems or programs that utilise the exported XML file, please be aware of the changed filename.
Once you have upgraded to JIRA 3.7, downgrading to a previous version is not a straightforward task and is not recommended. Please be aware that in JIRA 3.7 the database schema has changed.
If upgrade to JIRA 3.7 fails, the best way to proceed is to go back to the previous version of JIRA you were using, and to the latest pre-upgrade data that you have. The exact steps for doing this depend on how you have upgraded JIRA.
If you have created a new database for JIRA 3.7 by following the Upgrading JIRA safely instructions, you should be able to simply shutdown JIRA 3.7 and bring up the old version of JIRA your were using. The old version should be configured to use its old (unupgraded) database.
If you have upgraded JIRA by pointing JIRA 3.7 to an older database (and ran the SQL Scripts to upgrade the database schema), then you will need to: