Jira Software 8.8.x アップグレード ノート

Jira Software リリース ノート



アトラシアン コミュニティをご利用ください。


ここでは、Jira Software 8.8 へのアップグレードに関する重要な注意事項について説明します。

このリリースの新機能と改善の詳細については、「Jira Software 8.8.x リリース ノート」を参照してください。 

 アップグレード ノート

Increase pool-max-size on upgrade

If you're upgrading from Jira 7.x to Jira 8.x we recommend changing the pool-max-size parameter to 40 in your dbconfig.xml before the upgrade. Leaving the default of 20 can sometimes lead to “ResultSet Closed” errors during re-indexing on 8.x. For information on implementing the change, see Tuning database connections.

バージョン ビューの読み込み速度を上げるのに役立つ新しい API

Available from Jira 8.8.1

To help the Versions view in project settings load faster and avoid possible timeouts on large instances, we have changed the endpoint it called. 

Now, instead of .../release/allversions we use GET /rest/projects/1.0/project/<project_key>/release/allversions-nodetails to return the list of all project versions together with their data such as their name, status, or description (except the progress data). Archived versions are also returned. 

We also changed the way the information about the number of issues in each status category (To do, In progress, Done) related to each version is returned. This data, collectively known as Progress, is now lazy-loaded as the page is scrolled and uses a separate new endpoint. 

The old endpoint is still working however, will not be used by the releases including and following Jira 7.13.14, 8.5.5, 8.8.1 and 8.9. 

New endpointData it retrieves



List of project versions and their data
POST /rest/projects/1.0/project/<project_key>/release/details/progressProgress for each version

This is not a breaking change. 

Fetching updates to be fixed for Jira in version 8.8.2

If you use Jira with other Atlassian products such as Bamboo, Bitbucket or Fisheye/Crucible, you might have experienced it getting stuck paging over issue updates. This happens when the collective number of results to fetch is bigger than 50. We have worked on a fix and will bundle it in Jira version 8.8.2. Make sure you upgrade to this version for Jira to update without further issues.

G1 GC enabled by default for Java 11

If you’re running Jira with Java 11, Garbage First Garbage Collection (G1 GC) will be enabled by default. We’ve already been recommending this method when tuning garbage collection, so now you’ll get it out of the box. G1 GC is more efficient and improves performance, especially in environments with large Java heap.

Java バージョンDefault GCRecommended GC
Java 11G1 GC
  • G1 GC for large Java heap
  • ParallelGC for small Java heap*
Java 8ParallelGCParallelGC

*Our performance tests have shown that you might benefit from ParallelGC if you have a relatively small Java heap. The difference is not big, but you can consider switching back to ParallelGC if you’re having problems with performance.

How do I change the GC method?

To change the default GC method:

  1. Jira を停止します。

  2. Edit the setenv.sh/.bat file, and search for JVM_GC_ARGS. You’ll find available parameters described inside.

  3. If you’re running Jira as a service on Windows, you’ll also need to modify the gc-params-service.bat file.

All mail handlers supported

In Jira 8.6 we decided to deprecate two email handlers that do not use regex: ”Add a comment from the non-quoted email body” and ”Create a new issue or add a comment to an existing issue” (see the announcement). We advised users to switch to the handlers which use regular expressions to get rid of unwanted content such as email footers or signatures. 

Since then, we’ve received important feedback on our deprecation statement and, as a result, we decided to revert it.

We will not be deprecating the two mail handlers and instead will work on adding regular expression to the existing handlers to help admins manage the unwanted content added to Jira issues via email.

新しい API エンドポイント

As a result of introducing the Advanced auditing feature, we've added new REST endpoints. For more information, see here


The improved audit log we're introducing in Jira 8.8. requires us to migrate your existing audit log (up to 10 million records) on upgrade.

We migrate the existing events to the database.

Depending on the database you're using and the size of your current audit log, it might take up to several hours to migrate all the data. The migration runs in the background for all Server and Data Center upgrade paths (ZDU included) and does not stop Jira being operational. 

You can use the jira.advanced.audit.log.migration.limit flag in the Jira properties file to limit the number of events you want to migrate or to turn off the migration altogether. If you decide to turn off migration, your new audit log will only show the events that happen after upgrade. 

While migration is happening the new events are buffered and when migration is complete the buffer is released.

Before the migration happens we also run an additional heath check to see if you have enough extra free disk space (on the jira-home partition) to accommodate the new audit log. 

Expected changes to incoming mail settings (Jira 8.10)

In response to Google and Microsoft deprecating Basic Authentication, we will soon be adding OAuth 2.0 authentication methods for incoming email (so far using the IMAP and POP3 protocols). We’ll also backport it to the supported Enterprise releases. If you currently use email to create issues and issue comments, you will need to reconfigure your incoming mail settings. 

We treat this work with highest priority and aim to provide the solution ahead of the deadlines set by Google and Microsoft so that you have time to upgrade. 

OAuth 2.0 support will mean changes in to the incoming mail settings and the way you configure the incoming email server. It's a good idea to plan to take the time after your upgrade to review the changes so that your instance's email handlers keep working. 



In Jira 8.8, we're making the following changes:

We're stopping the support for the following platforms:

  • SQL Server 2012

  • PostgreSQL 9.4

  • Solaris

  • Oracle 12c R1

  • PostgreSQL 9.5

For more details, see End of support announcements.

Deprecating Hipchat

現在、Jira バージョン 8.11 以降での Hipchat プラグインのサポートおよびバンドルの廃止を予定しています。
これは、Hipchat Cloud は 2019 年 2 月に、Hipchat Data Center は 2019 年 9 月に、Hipchat Server は 2020 年 6 月にサポートが終了されるためです。

If you have not already, make sure you migrate to other chat solutions before Jira 8.11.


See Preparing for Jira 8.8 for any important changes regarding apps.


Jira バージョン 8.x.x からアップグレードする場合 

See Upgrading Jira applications for complete upgrade procedures, including all available upgrade methods and pre-upgrade steps. For a more tailored upgrade, go to  > Applications > Plan your upgrade. We’ll recommend a version to upgrade to, run pre-upgrade checks, and provide you with a custom upgrade guide with step-by-step instructions.

As the result of introducing the Advanced auditing feature, we'll be migrating your old audit log (up to 10 million records) on upgrade. Depending on the platform you're using and the size of your audit log, the migration might take up to several hours.

If you migrate with ZDU, your migration task will run in the background, and Jira will still be accessible to users.

You can use the jira.advanced.audit.log.migration.limit flag in the Jira properties file to limit the number of events you want to migrate or to turn off the migration altogether. In that case, you will only see the new events in your upgraded Audit log view, and the past events will remain invisible until you have performed the migration.

最終更新日 2020 年 7 月 3 日


Powered by Confluence and Scroll Viewport.