JIRA 4.3 : Aggregated JIRA 3.x Upgrade Guides
This page last changed on Sep 08, 2008 by alui.
This page contains a live aggregate of all JIRA upgrade guides since version 3. You can also view the lists of Release Notes or Upgrade Guides for JIRA. JIRA 2.x to 3This page lists a few things to be aware of when upgrading from previous releases of JIRA to JIRA 3. To perform the actual upgrade, see the upgrade documentation. Existing SMTP Mail Server 'From' address may break notifications (JRA-5089)In JIRA 3, email notification 'From' addresses now contain the reporter name, eg. "Joe Bloggs (JIRA) <jira@company.com>", where "jira@company.com" is set by the admin as the SMTP mail server From address. If you have this address to already include a name (eg "Tech Support <jira@company.com>", then email notifications will fail with errors like: 2005-01-06 11:30:53,856 ERROR [atlassian.mail.queue.MailQueueImpl] com.atlassian.mail.MailException: Sending failed; nested exception is: javax.mail.internet.AddressException: Missing '<' in string ``"Joe Bloggs (JIRA)" <Tech Support <jira@company.com>>'' at position 62 FixThe fix is to edit WEB-INF/classes/jira-application.properties, and change the following property value jira.option.include.user.in.mail.from.address = true
Invalid characters break XML importJIRA's recommended upgrade process involves deploying an XML backup of your data. Some users will find that the import fails with this error: This is usually because the database contains control characters that cannot be FixThe fix is to follow these instructions to remove the invalid characters from the XML before import. JIRA 3.0 to 3.1This page lists a few things to be aware of when upgrading from JIRA 3.0.x to JIRA 3.1. To perform the actual upgrade, see the upgrade documentation. For upgrading from JIRA 2.x to JIRA 3.x see JIRA 3.0 Upgrade Notes MySQL Users dB upgrade (JRA-5635)The size of the descriptor field in the jiraworkflow table has been increased. MySQL users will see warnings when they start their app server. This can be fixed by running the SQL below. This will also allow for Workflows of up to 4GB as opposed to just 64k JIRA 3.1 to 3.2This page contains information you need to know when upgrading to JIRA 3.2. The general upgrade instructions can be found here.
Notifications now respect permissionsIn 3.2, JIRA respects the permission scheme and security levels when sending notifications (see JRA-5743. People who won't be able to see an update online won't get a notification email. This has one important effect: if you have a project where:
This can be fixed by creating a user (eg. 'developers') for the email address, making it a member of a group that has 'Browse' permission, and adding it as a recipient of notifications. The raw email address should then be removed from the notification scheme, as it serves no purpose. JIRA 3.2 to 3.3JIRA 3.3 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.3 from JIRA 3.2.x. If upgrading from an older version of JIRA, please go to the complete list of Upgrade Guides, and read the notes for each version you are skipping during the upgrade. When upgrading JIRA please follow the general upgrade instructions keeping in mind the information below. Known incompatibilities3.3.x is not a good release for IBM shops:
Websphere or DB2 users, please stick with 3.2.x or move on to 3.4.x or higher, where these problems have been resolved. Notes on upgrading
JIRA 3.3 to 3.3.xJIRA 3.3.1 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.3.1 from JIRA 3.3.
When upgrading JIRA please follow the general upgrade instructions keeping in mind the information below:
JIRA 3.3.x to 3.4.xJIRA 3.4 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.4 from JIRA 3.3.3. If upgrading from an older version of JIRA, please read the Upgrade Guide for each version your are skipping during the upgrade. The complete list of Upgrade Guides is available here.
When upgrading JIRA please follow the general upgrade instructions keeping in mind the information below.
JIRA 3.4.1 Upgrade GuideThis section contains specific information you need to know when upgrading to JIRA 3.4.1 from JIRA 3.4. If upgrading from JIRA 3.3.3 please read the previous section as well. If upgrading from an older version than JIRA 3.3.3, please read the Upgrade Guide for each version your are skipping during the upgrade. The complete list of Upgrade Guides is available here. When upgrading JIRA please follow the general upgrade instructions keeping in mind the information below.
JIRA 3.4.2 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.4.2 from JIRA 3.4.1. If upgrading from an older version of JIRA, please read the Upgrade Guide for each version your are skipping during the upgrade. The complete list of Upgrade Guides is available here.
JIRA 3.4.3 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.4.3 from JIRA 3.4.2. If upgrading from an older version of JIRA, please read the Upgrade Guide for each version your are skipping during the upgrade. The complete list of Upgrade Guides is available here.
JIRA 3.4.x to 3.5.xJIRA 3.5 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.5 (release notes) from JIRA 3.4.3. If upgrading from an older version of JIRA, please read the Upgrade Guide for each version your are skipping during the upgrade. The complete list of Upgrade Guides is available here. JIRA 3.5 Jira Service extension
In JIRA 3.5 the getName() and setName(String name) methods was added to the com.atlassian.jira.service.JiraService interface. This method should return and set the name of the service respectively. The name of the service can be used to identify a service uniquely. (Fixed made due to JRA-8352 bug) Therefore, if you have implemented this interface, you will need to implement these methods and recompile your service(s) before deploying it into JIRA 3.5. If you have extended a JIRA class instead, e.g. com.atlassian.jira.service.AbstractService or com.atlassian.jira.service.JiraServiceContainer you do not need to modify your custom services. Introduction of global Bulk Change permissionJIRA 3.5 introduces the global Bulk Change permission. This permission governs the ability to execute the bulk change operations:
An upgrade task has been added to grant the new Bulk Change permission to all groups with the global JIRA Users permission. The JIRA documentation includes further details on this new permission.
CustomFieldPersister changesCustomFieldPersister is used to store custom field values to database. The methods of this class has been refactored to remove the redundant parameter, defaultValueMarker. For example, the create values method went from: to: You will need to update and recompile any CustomFieldType that you wrote to use this new interface. VersionCFType ChangesThis affects plugin writers who uses the version custom field VersionCFType. The change is that previously the Transport Object type was a single Version object, but it is now a collection that contains a single Version object. This was done to handle an improved version custom field which can be a mutli-select version custom field as well JIRA 3.5.1 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.5.1 from JIRA 3.5. If upgrading from an older version of JIRA, please read the Upgrade Guide for each version your are skipping during the upgrade. The complete list of Upgrade Guides is available here.
JIRA 3.5.2 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.5.2 from JIRA 3.5.1. If upgrading from an older version of JIRA, please read the Upgrade Guide for each version your are skipping during the upgrade. The complete list of Upgrade Guides is available here. Issue Event Changelog Can Now Be Null
In JIRA 3.5.2, the IssueEvent object thrown as a result of an edit operation, may now return null from a getChangeLog() call. The case where this happens is when a user chooses to edit an issue but only leaves a comment and makes no other changes to the issue. Prior to 3.5.2 no event was fired in this case and this was identified as a bug (JRA-9415) and has since been fixed. Check any calls to getChangeLog() for null. JIRA 3.5.3 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.5.3 from JIRA 3.5.2. If upgrading from an older version of JIRA, please read the Upgrade Guide for each version your are skipping during the upgrade. The complete list of Upgrade Guides is available here.
JIRA 3.5.x to 3.6.xJIRA 3.6 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.6.x from JIRA 3.5.x. If upgrading from an older version of JIRA, please go to the complete list of Upgrade Guides, and read the notes for each version you are skipping during the upgrade. When upgrading JIRA please follow the general upgrade instructions keeping in mind the information below. Database Intensive Upgrade TaskTo introduce the Custom events to JIRA, it was necessary to upgrade a large data set within JIRA's database for 3.5.x and earlier releases. Depending on the size of your JIRA data the upgrade task (number 150) might get your DBMS to do a lot of work which might take some time. The exact amount of time also depends on the processing power of the machine running JIRA's database. Please be patient with the upgrade task and do not restart JIRA while the upgrade is in progress. The upgrade task will report on its progress to JIRA's log file as it upgrades your data. The following is the sample output that the upgrade task will produce. As you can see the upgrade task took roughly 5 and a half minutes to modify over 660,000 records in the database. Workflow Post Functions
JIRA stores its workflows in the database. During the upgrade, these workflows will be upgraded automatically. However, if you have stored your workflows on disk (outside the database), you will need to follow these instructions to upgrade the workflows manually. Previously, workflow post functions referenced the event to fire through a string value of the event name. All post functions now reference the event through a numeric ID value. As mentioned, all workflows stored within JIRA will be automatically updated. However, all workflows saved to disk - external to JIRA - should be updated manually as follows. The actual workflow XML file should be updated as follows: For each workflow post function that accepts the event ID as an argument:
By default, the only post functions that accept event IDs are FireIssueEventFunctions. Therefore, unless you have implemented your own custom post function that also deals with events, you will only need to update the arg tags for the FireIssueEventFunctions everywhere in the workflows. For example, FireIssueEventFunction for create issue workflow transition looked like: and needs to be changed to: Custom Events
Releases before JIRA 3.6 did not allow users create custom events. If you have modified the JIRA source to add custom events - please follow these instructions. If you have previously defined a custom event within JIRA - it is necessary to add appropriate entries to the following files:
The system-event-types.xml file requires name and description details of the previously added custom event. For example, if the custom event type "Issue Frozen" was added to the system - the following entry should be added to the XML file: The elements provide the following information:
The email-template-id-mappings.xml file requires an entry mapping the new custom event to an associated velocity email template. This mapping is used when a notification is sent for this event. Following from the above example, the following entry would be made: The id should match that of the event as specified in the system-event-types.xml The template entity should reference the Velocity template to be used in email notifications of this event. A HTML and text version should be provided in the appropriate directory (html or text) at: <JIRA>/src/etc/java/templates/email/
Custom Listeners
For all users who have added custom written listeners to JIRA, it might be necessary to update the listener to follow the new JIRA 3.6 API. There are two things to look out for:
The signature of the method workflowEvent in the IssueEventListener has changed from: to: Note: the type parameter has been removed. If you have implemented IssueEventListener directly or have extended AbstractIssueEventListener and have overridden the method workflowEvent, you will need to change and recompile your listener before installing JIRA 3.6. In JIRA 3.6, the event type ID can be retrieved by calling the following method on the IssueEvent object: However, the returned value of the getId() method is different to the values of the type parameter that was passed to the workflowEvent method. The following table represents these differences:
Also, the getIssue() method of the IssueEvent object has changed to return an Issue object instead of a GenericValue object representing an issue. Users who have created and added custom listeners must update the listener to now operate with the Issue object. For example: As a quick fix, you can modify your listener to use event.getIssue().getGenericValue(). The event type ID constants are now only available from the class EventType. Any use of the original constants must be updated to use the EventType constants. For listeners that reference an event ID by its numeric value - it is necessary to ensure that the IDs now match those as defined in EventType. Custom permission types
The SecurityType interface, used to implement permission types ('single user', 'group' etc) has had a getUsers() method added. If you have implemented your own SecurityType you will need to implement this. See the source of current implementations (eg. GroupCF) for tips. Plugin upgrades requiredAs usual, you should check whether the plugins you use are compatible with the new release. Generally, plugins (like the Subversion plugin or JIRA toolkit ) need to be upgraded when JIRA is upgraded. See the list of plugins at: http://confluence.atlassian.com/display/JIRAEXT/Home JIRA 3.6.1 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.6.1 from JIRA 3.6. If upgrading from an older version of JIRA, please read the Upgrade Guide for each version your are skipping during the upgrade. The complete list of Upgrade Guides is available here.
JIRA 3.6.2 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.6.2 from JIRA 3.6.1. If upgrading from an older version of JIRA, please go to the complete list of Upgrade Guides, and read the notes for each version you are skipping during the upgrade. When upgrading JIRA please follow the general upgrade instructions keeping in mind the information below. Maximum Active Databased Connections
In version of JIRA before 3.6.2, the maximum number of database connections was limited to 8 by default. If JIRA was used by more than 8 concurrent users or under very haeavy usages, the users could experience delays or JIRA could hang. In JIRA 3.6.2 the default number of maximum active database connections has been increased to 20. When upgrading to JIRA 3.6.2, please ensure that your database will allow JIRA to establish 20 connections, or decrease this number to desired value. To adjust the number of connections change the value of the maxActive attribute of the jdbc/JiraDS resource in config/server.xml file. JIRA has to be restarted to apply the change. JIRA 3.6.3 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.6.3 from JIRA 3.6.2. If upgrading from an older version of JIRA, please read the Upgrade Guide for each version your are skipping during the upgrade. The complete list of Upgrade Guides is available here.
JIRA 3.6.4 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.6.4 from JIRA 3.6.3. If upgrading from an older version of JIRA, please read the Upgrade Guide for each version your are skipping during the upgrade. The complete list of Upgrade Guides is available here.
JIRA 3.6.5 Upgrade GuideThis page contains specific information you need to know when upgrading to JIRA 3.6.5 from JIRA 3.6.4. If upgrading from an older version of JIRA, please read the Upgrade Guide for each version your are skipping during the upgrade. The complete list of Upgrade Guides is available here.
JIRA 3.6.x to 3.7.x
JIRA 3.7 Upgrade NotesThis 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.
Database Schema ChangesDue 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.
Request Context ChangesIn 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:
Integrity ChecksIn 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). Change of commentLevel to groupLevel in the Comment and TransitionWorkflow jelly tagsWe 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. Change of level to grouplevel in the XML view of a Comment
Change to the RemoteComment object used via SOAP/RPC pluginThe 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:
ActionManager removedThe ActionManager interface has been removed and its functionality has been delegated to new interfaces. For details please refer to ActionManager Removed documentation Removal of 'Backend Actions'
Issue EventsWe 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. Renaming of XML export fileBy 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. Confluence Users Only - Pre 2.2.10 Confluence Must Be Patched To Use JIRA Issues MacroUnable to render {include} Couldn't find a page to include called: DOC:JIRA 3.7 Link Format Change JIRA 3.7 Downgrade NotesOnce 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:
JIRA 3.7.1 Upgrade GuideThis page contains specific information you need to know when upgrading from JIRA 3.7 to JIRA 3.7.1. If upgrading from an older version of JIRA, please read the Upgrade Guide for each version your are skipping during the upgrade. The complete list of Upgrade Guides is available here.
JIRA 3.7.2 Upgrade GuideThis page contains specific information you need to know when upgrading from JIRA 3.7.1 to JIRA 3.7.2. If upgrading from an older version of JIRA, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here.
Upgrading from JIRA 3.7.2 to 3.7.3Please follow the JIRA general upgrade instructions. Upgrading from JIRA 3.7.1 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here. Upgrading from JIRA 3.7.3 to 3.7.4Please follow the JIRA general upgrade instructions. Upgrading from JIRA 3.7.2 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here. JIRA 3.7.x to 3.8.xUpgrading from JIRA 3.7.4 to 3.8Please follow the JIRA general upgrade instructions. Additionally, please note the following:
Upgrading from JIRA 3.7.3 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here. Upgrading from JIRA 3.8 to 3.8.1Please follow the JIRA general upgrade instructions.
Upgrading from JIRA 3.7.4 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here. JIRA 3.8.x to 3.9.xUpgrading from JIRA 3.8.1 to 3.9Please follow the JIRA general upgrade instructions. Additionally, please note the following: In this version, there has been a change to the database which may cause problems for some customers. The Recommended Upgrade MethodIf you follow the recommended export/import upgrade procedure you should not experience any problems! Pointing JIRA 3.9 at an existing, non-empty databaseSome customers have a good reason for not following the recommended upgrade method. Using this method may result in database errors in your logs. You can avoid this if you modify your table structure manually, but the procedure is different depending on whether you have already started JIRA. To avoid this, BEFORE you upgrade JIRA using this method, you can just drop the qrtz_cron_triggers table. This table has not been used by JIRA before 3.9, so it should be empty. If you have ALREADY started JIRA 3.9 using your existing database, you may see the following log messages when JIRA starts up: The reason for this is that we have incorrectly changed a column in the qrtz_cron_triggers table. The intention was to fix a misspelling, but all we did was remove an underscore ("_")! The old column name is "CRON_EXPERSSION". The new column name is "CRONEXPERSSION". Note that both columns spell the word "expression" incorrectly. To remove the error message, you must remove the old column as it is redundant. This column will not contain any data. The following table shows all columns in the qrtz_cron_triggers table. Columns that should be present are in green and columns that should be deleted are in red.
To delete the column, you can use SQL, but this may be slightly different between databases. Here's how it might look: alter table qrtz_cron_triggers drop column CRON_EXPERSSION; The data in this tableIf you have users who have subscribed to issue filters, note that existing SimpleTriggers (time intervals) will be automatically converted into CronTriggers during the JIRA upgrade. In some cases, there may not be an exact mapping of time intervals to Cron Expressions, and approximations will be made (e.g. 'Every 5 weeks' will be converted to 'Once a month'). If this happens, the JIRA upgrade process will send an email to the user to inform them of the new schedule. Upgrading from JIRA 3.8 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here. Upgrading from JIRA 3.9 to 3.9.1Please follow the JIRA general upgrade instructions. Upgrading from JIRA 3.8.1 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here. Upgrading from JIRA 3.9/3.9.1 to 3.9.2Please follow the JIRA general upgrade instructions. Upgrading from JIRA 3.8.1 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here.
Upgrading from JIRA 3.9.2 to 3.9.3Please follow the JIRA general upgrade instructions. Upgrading from JIRA 3.9.1 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here. JIRA 3.9.x to 3.10.xUpgrading from JIRA 3.9.3 to 3.10Please follow the JIRA general upgrade instructions, plus note the following: 1. PluginsThere is a new version of the JIRA Calendar Plugin that links to the new 'Project Version' pages. This new version of the plugin is not backwards compatible. Please note that the Kaamelot plugin for JIRA has not yet been updated. If you are currently using this plugin, you may want to hold off the upgrade to JIRA 3.10 until a compatible version of this plugin has been released. 2. Developer NotesThe ordering of the ListOrderedMap returned by SchemePermissions.getSchemePermissions() has changed. This also means that the order of the RemotePermission[] array returned by the RPC Plugin's JiraSoapService.getAllPermissions() method has changed. If you have extended your instance of JIRA please confirm that any remote applications retrieving permissions via SOAP still work. You may encounter problems if you have been retrieving specific permissions by their array index. Database changesIn JIRA 3.10, the worklog records have moved from the 'jiraactions' database table to the new 'worklog' table. This new table contains the following columns: Table "public.worklog" Column | Type | Modifiers --------------+--------------------------+----------- id | numeric(18,0) | not null issueid | numeric(18,0) | author | character varying(255) | grouplevel | character varying(255) | rolelevel | numeric(18,0) | worklogbody | text | created | timestamp with time zone | updateauthor | character varying(255) | updated | timestamp with time zone | startdate | timestamp with time zone | timeworked | numeric(18,0) | Upgrading from JIRA 3.9.2 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here.
Upgrading from JIRA 3.10 to 3.10.1Please follow the JIRA general upgrade instructions. Upgrading from JIRA 3.9.3 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here. Upgrading from JIRA 3.10.1 to 3.10.2Please follow the JIRA general upgrade instructions. Upgrading from JIRA 3.9.3 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here. JIRA 3.10.x to 3.11.xUpgrading from JIRA 3.10.x to 3.11Please follow the JIRA general upgrade instructions, plus note the following: Administrative notes
PluginsUpdating plugins 3rd Party and personal plugins may also be affected (esp. if using lucene to store dates). These will need to be updated as well. If these are updated after the upgrade (instead of as part of the upgrade), you will need to do a reindex. A failure to update these plugins will result in lots of errors that look like: Error 12007-07-25 15:23:27,553 http-8090-Processor4 ERROR [charting.charts.createdvsresolved.CreatedVsResolvedChart] Could not create velocity parameters For input string: "20070725144811" java.lang.NumberFormatException: For input string: "20070725144811" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Long.parseLong(Long.java:415) at org.apache.lucene.document.DateField.stringToTime(DateField.java:100) at org.apache.lucene.document.DateField.stringToDate(DateField.java:104) at com.atlassian.jira.ext.charting.data.DatePeriodStatisticsMapper.getValueFromLuceneField(DatePeriodStatisticsMapper.java:47) at com.atlassian.jira.ext.charting.data.OneDimensionalObjectHitCollector.adjustMapForValues(OneDimensionalObjectHitCollector.java:57) at com.atlassian.jira.ext.charting.data.OneDimensionalObjectHitCollector.collect(OneDimensionalObjectHitCollector.java:46) at org.apache.lucene.search.IndexSearcher$1.collect(IndexSearcher.java:137) at org.apache.lucene.search.Scorer.score(Scorer.java:49) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:146) at org.apache.lucene.search.Searcher.search(Searcher.java:118) at com.atlassian.jira.issue.search.providers.LuceneSearchProvider.search(LuceneSearchProvider.java:111) ... Error 2Caused by: java.lang.NoSuchMethodError: org.apache.lucene.document.Document.add(Lorg/apache/lucene/document/Field;)V at com.atlassian.jira.plugin.labels.LabelSearcher.index(LabelSearcher.java:95) at com.atlassian.jira.issue.index.indexers.impl.DefaultCustomFieldIndexer.addIndex(DefaultCustomFieldIndexer.java:54) at com.atlassian.jira.issue.index.IssueDocument.getDocument(IssueDocument.java:34) at com.atlassian.jira.issue.index.IssueDocumentBuilderImpl.get(IssueDocumentBuilderImpl.java:14) at com.atlassian.jira.issue.index.SingleThreadedIssueIndexer$IssueAndCommentCreator.handleIssueIndexing(SingleThreadedIssueIndexer.java:404) at com.atlassian.jira.issue.index.SingleThreadedIssueIndexer$AbstractIssueAndCommentHandler.indexIssuesAndComments(SingleThreadedIssueIndexer.java:318) at com.atlassian.jira.issue.index.SingleThreadedIssueIndexer.indexIssuesAndComments(SingleThreadedIssueIndexer.java:122) at com.atlassian.jira.issue.index.MultiThreadedIssueIndexer.indexIssuesAndComments(MultiThreadedIssueIndexer.java:41) at com.atlassian.jira.issue.index.SingleThreadedIssueIndexer$2.perform(SingleThreadedIssueIndexer.java:113) at com.atlassian.bonnie.ConcurrentLuceneConnection.withWriter(ConcurrentLuceneConnection.java:296) at com.atlassian.jira.issue.index.SingleThreadedIssueIndexer$1.perform(SingleThreadedIssueIndexer.java:107) at com.atlassian.bonnie.ConcurrentLuceneConnection.withWriter(ConcurrentLuceneConnection.java:296) at com.atlassian.jira.issue.index.SingleThreadedIssueIndexer.indexIssues(SingleThreadedIssueIndexer.java:102) at com.atlassian.jira.issue.index.SingleThreadedIssueIndexer$6.perform(SingleThreadedIssueIndexer.java:219) ... If you see these errors, please ensure that you are using the latest compatible version of the plugin for 3.11. If there is no supported version for 3.11, please contact the plugin developer via the plugin's homepage. Developer notesModification to SOAP clients If you would like your SOAP client to work against multiple versions of JIRA then you need to use the latest stubs that have been generated against JIRA 3.11. You will need to not use any of the new functionality and you will need to remember that the isSubTask variable in the RemoteIssueType objects will be defaulted to false. ThreadLocalQueryProfiler searchers have been moved to ThreadLocalSearcherCache Lucene Upgrade Database changesThere were no database changes in this release. Upgrading from JIRA 3.9.x and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here.
JIRA 3.11 to 3.12.xUpgrading from JIRA 3.11 to 3.12Please follow the JIRA general upgrade instructions, plus note the following:
Upgrading from JIRA 3.10.2 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here.
Using the Trusted Applications feature with CrowdPlease note that older versions of the Crowd client, (i.e. version 1.2.1 or earlier), can interfere with the correct operation of the Trusted Applications feature. If you are enabling Trusted Applications and using Crowd, please ensure that your Crowd client is version 1.2.2 or later. Upgrading from JIRA 3.12 to 3.12.1Please follow the JIRA general upgrade instructions Upgrading from JIRA 3.11 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here.
Upgrading from JIRA 3.12.1 to 3.12.2Please follow the JIRA general upgrade instructions Upgrading from JIRA 3.11 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here.
Upgrading from JIRA 3.12.2 to 3.12.3Please follow the JIRA general upgrade instructions Upgrading from JIRA 3.11 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here.
JIRA 3.12.x to 3.13Upgrading from JIRA 3.12.xx to 3.13Please follow the JIRA general upgrade instructions, plus note the following: 1. Introduction of Favourite Dashboards and Filters
2. Tomcat, MySQL database connection dropouts
3. Changes to jira-application.properties
4. Support for Portlet Plugins with JSP Views Discontinued
5. Updates to JIRA SOAP and XML-RPC APIs6. Crowd Cache Timeout
Upgrading from JIRA 3.12 and earlierIn addition to the above, please read the Upgrade Guide for every version you are skipping during the upgrade. The complete list of Upgrade Guides is available here. |
![]() |
Document generated by Confluence on Mar 27, 2011 18:43 |