Version History

In this page

Version history

Version	Date	Notes
6.4.0	19/01/2024	Security update release.	Release Notes & Upgrade Guide	Download
6.3.0	15/11/2023	Preparation for Jira Server end-of-support.	Release Notes & Upgrade Guide	Download
6.2.0	27/12/2022	Security update release.	Release Notes & Upgrade Guide	Download
6.1.0	08/07/2022	"... must contain issue keys" type conditions support the issues moved between projects. Configurable "Did you mean?".	Release Notes & Upgrade Guide	Download
6.0.0	05/07/2022	Compatibility release for Jira 9.	Release Notes & Upgrade Guide	Download
5.0.1	18/02/2021	Maintenance version for DevOps automations.	Release Notes & Upgrade Guide	Download
5.0.0	27/01/2021	Support for DevOps automations (compatibility release for the upcoming Better DevOps Automation for Jira app).	Release Notes & Upgrade Guide	Download
4.3.0	22/10/2019	Improved guides for Bitbucket Server, Bitbucket Data Center, Bitbucket Cloud, GitHub, GitHub Enterprise, GitLab Self-Managed and GitLab.com. "Did you mean?". Clone commit policy. 3 new bypass patterns.	Release Notes & Upgrade Guide	Download
4.2.0	30/09/2019	Extended security model.	Release Notes & Upgrade Guide	Download
4.1.0	19/02/2019	Compatibility release for Jira 8.	Release Notes & Upgrade Guide	Download
4.0.0	05/01/2019	Support for the new Data Center Approved Apps program.	Release Notes & Upgrade Guide	Download
3.0.2	06/07/2018	Major performance improvements for super-large Git repositories.	Release Notes & Upgrade Guide	Download
3.0.1	22/06/2018	Maintenance release.	Release Notes & Upgrade Guide	Download
3.0.0	12/06/2018	Tag verification. Branch verification. New configuration options.	Release Notes & Upgrade Guide	Download
2.4.0	21/11/2017	Compatibility release for Jira 7.6.	Release Notes & Upgrade Guide	Download
2.3.0	04/07/2017	Compatibility release for Jira 7.4.	Release Notes & Upgrade Guide	Download
2.2.0	06/01/2017	Compatibility release for Jira 7.3.	Release Notes & Upgrade Guide	Download
2.1.0	02/09/2016	Compatibility release for Jira 7.2. More precise execution of JQL searches.	Release Notes & Upgrade Guide	Download
2.0.1	11/07/2016	Maintenance version (fast JQL evaluation, bugfixes).	Release Notes & Upgrade Guide	Download
2.0.0	03/05/2016	Token auth. Git client-side verifications. Support for Bitbucket Cloud & GitHub.	Release Notes & Upgrade Guide	Download
1.4.0	08/01/2016	Support for Jira Data Center.	Release Notes & Upgrade Guide	Download

Release notes

6.4.0

This release introduces security fixes for potential vulnerabilities.

Security fixes

The internal versions of the following dependencies were updated:

1. Apache Commons Collections

We strongly suggest upgrading to this app version as soon as possible!

Upgrading from 6.3.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

6.3.0

This version introduces a few changes as a preparation for the Jira Server end-of-support.

Important: don't forget that Jira Server will be retired in February 2024!

Improvements

• All URLs are updated to point to the documentation of the app's Data Center version.

Notable changes

• This version introduces a few small limitations when using the app with trial licenses. (If you are using the app with a paid license, you are not affected.)

Bugfixes

• Fixed: Hook script diagnostic mode mistakenly detects Python version 3.10+ older than 3.3, and the test fails with "Your Python version is 3.10.12 but you need at least 3.3 (or 2.7 from the 2.x product line) to properly run the hook scripts".

Upgrading from 6.2.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

Note that to actually enjoy the Python version detection bugfix above, new hook scripts should be generated. Because it can be quite some work if you have a large number of repositories, we suggest generating new hook scripts only if both of these are true in a repository:

1. You are using Python version 3.10 or newer on the computer that hosts the repository
2. And, you actually want to use the diagnostic mode (to test the integrity of the hook script in the repository)

Otherwise, you can just continue using the existing hook script (and not do anything), because the bug doesn't affect you. You can, of course, generate a new hook script in the repository any time later, and enjoy the bugfix from that point of time.

6.2.0

This release introduces security fixes for potential vulnerabilities.

Security fixes

The internal versions of the following dependencies were updated:

1. Apache Commons Compress

We strongly suggest upgrading to this app version as soon as possible!

Upgrading from 6.1.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

6.1.0

This release introduces a handful of features requested by our power users.

"... must contain issue keys" type conditions support the issues moved between projects

As you probably now, when moving issues between projects, they will change their issue keys. For example, an issue moved from project FOO to project BAR will change its key from "FOO-5" to "BAR-7".

Previous app versions accepted only the new key, "BAR-7" in our example. From this version, all conditions that work with JQL will accept both "FOO-5" and "BAR-7". This improvement helps to maintain precise commit-to-issue links over very long periods, multi-year or multi-decade projects, projects split, projects merged and so on.

Learn more about the "commit message must contain issue keys from a JQL query" condition.

Configurable "Did you mean?"

You can configure the limit (maximum count) of the suggested issues or even completely disable suggestions. Although discouraged, disabling suggestions can be useful when team members just blindly choose the first suggested issue, which is not necessarily the right one, thus undermining the traceability of commits. We believe that you should primarily educate them about the importance of choosing the right issue, but disabling suggestion is now there as an option.

Learn more about configuring "did you mean?".

Upgrading from 6.0.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

6.0.0

This version is a compatibility release for Jira 9.

Compatibility release for Jira 9

The next Jira major version has been released less about two weeks ago. The Midori team has been super-busy with updating the app to support the Jira 9 codebase, while also keeping the backward compatibility with Jira 6.3 (and all versions between 6.3 and 9).

It was challenging, but we're happy to announce this new app version with Jira 9 compatibility!

Upgrading from 5.0.1

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

5.0.1

This version fixes a major bug in 5.0.0 that would affect the upcoming Better DevOps Automation for Jira app (coming soon, fingers crossed!).

Upgrading from 5.0.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

5.0.0

This version prepares the foundation for a new Midori app called Better DevOps Automation for Jira.

Note that when upgrading from 4.3.0 to 5.0.0, there is no visible change in the Better Commit Policy for Jira app's already existing functionality. But, under the hood, it implements the API that will power the upcoming DevOps automation app.

Although the DevOps automation app is not publicly available at the time when this Better Commit Policy version is released, we suggest upgrading to this version right away. Read on why.

What is the Better DevOps Automation app?

This is an early notice that we are releasing a new DevOps automation app soon!

This no-code, low-code automation tool will allow you to create all kinds of DevOps automation rules. The rules can be started by accepted commits, rejected commits, branch creation, tag creation, and other events. It will work with every Version Control System (both centralized and distributed) that is supported by Better Commit Policy: Git, Bitbucket, GitHub, GitLab, Subversion and others!

Have you heard about Smart Commits in Bitbucket Cloud? We have something even cooler in store!

Better DevOps Automation will introduce the concept of Genius Commits. These will be "smarter than Smart Commits" and will be way more powerful for building DevOps workflows in Jira. These will allow you to use custom commands with custom logic in commit messages. For example, just write "@deploy prod" in the commit message to start the automation that deploys the given code version to your production instance. Or, use "@done" to transition to the user story to the Done status, "@scan" to start a source code analysis or "@build" to start an expensive CI build. There are countless use cases.

DevOps automation tools for Data Center and Server

Please note that no-code, low-code DevOps automation features, that are so easy to use as a drag-and-drop interface are offered by Atlassian, but only for the Cloud deployment type. While we are planning to release our Better Commit Policy and DevOps Automation apps also for Jira Cloud in the future, we are focusing on Data Center and Server customers first.

For them, the best option today for automating DevOps processes and for connecting DevOps tools to Jira is to write and maintain custom scripts. It requires technical expertise to write and operate these.

The Automation for Jira app, however, already provides a user-friendly interface for building complex automation rules and workflows even for non-technical people. With Better DevOps Automations, we are unlocking the same ease of use also for DevOps automations!

What should you do right now?

Don't forget to:

1. Lock in a massive 50% discount! Are you on board with DevOps automation? Once it's available at Atlassian Marketplace, we are offering Better DevOps Automation for 50% off for Better Commit Policy customers. You can lock in the discount if you purchase within 3 months after launch. You only need to join our Slack channel and drop us a line. We will fix you up with a promo code.
2. Get your hands on it before anyone else! No sneak peek video and "signup for a wait list" bullsh*t. Join our Slack channel and claim early assess to the app, and try it yourself as soon as it fits you.
3. Join the conversation. As an existing Better Commit Policy user, you are invited to our Slack channel where you can ask questions about Better DevOps Automation directly from the developers.

Upgrading from 4.3.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

4.3.0

This version introduces improved guides for various Git management applications and several important new features.

Improved guides for Bitbucket Server, Bitbucket Data Center, Bitbucket Cloud, GitHub, GitHub Enterprise, GitLab Self-Managed and GitLab.com

Getting started with commit policies in the context of the popular web-based Git management applications can be a bit confusing. "How and where should I install the hooks if use the X application on the top of Git?" is a typical question that we received many times in the past.

In this version, we decided to redesign the interactions in the Hook Script Wizard and to rewrite the guides in the user manual to ease the first steps that to a working GitHub integration, for instance:

Notable changes:

• Bitbucket Server guide: users are more explicitly instructed to use the Better Commit Policy for Bitbucket app instead of low-level Git hooks.
• Bitbucket Data Center: instead of being mixed with Bitbucket Server, it has been moved to its own guide.
• Bitbucket Cloud: it has been rewritten from scratch. Users are now encouraged to ask for the missing "custom server-side pre-receive hooks" feature at Atlassian.
• GitHub: it has been rewritten from scratch. Users are now encouraged to ask for the missing "custom server-side pre-receive hooks" feature at GitHub.
• GitHub Enterprise: it has been newly added with detailed instructions.
• GitLab Self-Managed: it has been rewritten with more detailed instructions.
• GitLab.com: it has been rewritten from scratch. Users are now encouraged to ask for the missing "custom server-side pre-receive hooks" feature at GitLab.

Learn more about your particular Git management application by using the links above.

"Did you mean?" (intelligent issue key suggestions)

"Did you mean?" is a unique feature that makes fixing rejected commits faster and less frustrating by giving intelligent tips for the fix. Not only it can save time and efforts, it can also save the mental switch from the VCS client to Jira, plus the loss of focus caused by the switch.

Learn more about "did you mean?".

Clone commit policy

This new feature makes it easy to create a new commit policy based on an existing one, instead of defining that from scratch. It is super-useful when you have multiple projects that want to enforce a similar set of commit rules and conditions.

Learn more about cloning commit policies.

Bypassing complete changesets and single commits by commit messages and committers

The app has supported bypassing verification of complete changesets by commit messages since its initial version. This version introduces 3 additional ways, each being super-useful in certain situations:

1. Available in previous versions: the complete changeset can be bypassed if the commit message of any commit in it matches a regular expression.
2. New: the complete changeset can be bypassed if the committer user of any commit in it matches a regular expression. Useful for programmatic commits, e.g. for those created by CI/CD/build systems.
3. New: a single commit can bypassed if its commit message matches a regular expression. (Same as 1, but for one commit.)
4. New: a single commit can bypassed if its committer user matches a regular expression. (Same as 2, but for one commit.)

Learn more about the bypass patterns.

Improvements

• New REST API end-point to clone policies programmatically.

Upgrading from 4.2.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

4.2.0

This version introduces an extended, more flexible security model to ease managing commit policies in large Jira teams.

Extended security model (in nutshell: project administrators can manage policies!)

In previous app versions, the app used very simple rules: Jira administrators can manage all commit policies, users can view all commit policies, that's it! Although simplicity is great, this model didn't scale well to larger teams working with many commit policies. That's why starting from this version the app extends the old model with additional possibilities. (Note that the old model is still available by using the so-called "global commit policies".)

In the new model, commit policies can be optionally linked to Jira projects. When linked to a project, the commit policy becomes editable by the project administrators and visible by the project members.

We designed the new security model to use the standard Jira project permissions to control what users can do with commit policies. Consequently, you don't need to spend time with managing a new set of permissions. It will just work.

Learn more about the permissions.

Improvements

• New "Getting Started" page.
• Sharing the hook script package ZIP with your peers is explicitly discouraged in the hook script wizard UI (to avoid a common mistake).

Upgrading from 4.1.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

4.1.0

This version is a compatibility release for the Jira 8 line.

Upgrading from 4.0.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

4.0.0

As you probably know, Better Commit Policy already supports Jira Data Center deployments (i.e. clustered Jira). To be precise, those are supported since app version 1.4.0 (released in Jan 2016).

In 2018, Atlassian re-launched its Data Center program and introduced new development and testing criteria for "Data Center approved apps". This version is the official release for the revised program, tested to live up to the rigorous demands of Data Center environments.

Better Commit Policy is a Data Center approved app!

The followings have been done to comply with the revised development and testing requirements:

1. This version has been verified against the Atlassian's official Data Center technical checklist, which would identify potential non-cluster-safe parts in the app. All points are met.
2. This version has been tested in our internal AWS infrastructure which is using "c4.xlarge" type standard EC2 instances to host the Jira nodes. The testing confirmed that the app works correctly and consistently in clusters with 1, 2, 4 and 8 nodes (and anything in-between).
3. This version has been successfully tested with UPM 3.0, the new generation of the Universal Plugin Manager.

"Commit Policy Plugin for Jira" is now called "Better Commit Policy for Jira"!

With this version, we made a slight adjustment in the app's name due to the following reasons:

1. The new name is better aligned with the names of our other apps, forming a recognizable brand.
2. The term "plugin" was replaced by Atlassian first with "add-on" and then with "app". We decided to get rid of this completely.

You may still see the old name popping up here and there, until we roll out the change everywhere. Thanks for the patience!

Upgrading from 3.0.2

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

3.0.2

This version is coming with major (100x!) performance improvements around verifying pushes to super-large Git repositories.

More efficient computation of the "is existing" property for Git commits

Commit Policy Plugin for Jira 3.0.0 introduced a new mechanism to detect existing commits (commits that are pushed or merged to a repo, but already existing on another branch in the same repository). It helps to avoid re-verifying existing commits, not because of performance, but because the issues referenced by the existing commits may already be in another stage in their lifecycle (like in another status) at their second push, which could lead to sub-optimal development workflows and policies.

Although the original implementation of the "is existing" computation logic is working correctly, it did not scale to repositories with several hundred branches or with tens of thousands of commits. If it affected you, then your developers may have complained about unexpectedly slow pushes.

In the new app version, we implemented a better approach that is two orders of magnitude (100x) faster even in huge repositories! For instance, the verification of a large push to a mega-repo now completes in less than a second instead of 2 minutes.

Required Git version

To take advantage of the performance improvement, the app requires Git 2.11.0 or newer. If you use some older Git version (which is very unlikely), the new approach cannot be used, and the app will assume all commits as "new" (as it is the safer assumption) and continue working.

Upgrading from 3.0.1

Upgrade the app JAR as usual, through the Universal Plugin Manager and also upgrade existing Git pre-receive hook scripts if you are using large Git repositories with hundreds of branches or tens of thousands of commits.

If you were not experiencing slow pushes with the previous app version, then you can save the hook upgrade. Again: the previous hook script works correctly, but may eventually be slow in super-large Git repositories.

3.0.1

This version is a maintenance release to deliver a Subversion related bugfix.

Bugfixes

• Fixed: Subversion hook script fails to find branches and tags with Python 3.

Upgrading from 3.0.0

Upgrade the app JAR as usual, through the Universal Plugin Manager and also upgrade existing hook scripts for Subversion if you are using Python 3. For Python 2, there is no need to upgrade the hook scripts.

3.0.0

In short, this is our most feature-packed release since Commit Policy Plugin 1.0.0.

It introduces new conditions that enable powerful verification on branches and tags, new options to toggle verification on already-existing and merge commits, plus numerous improvements.

Branch verification

This version introduces 2 conditions to verify branches to give strict control on VCS branches. You can enforce rules on branch names and linking branches to Jira issues:

Important: don't forget to complete the upgrade steps below, as that is critical for this feature.

Learn more about verifying branches.

Tag verification

In addition to branch verification, this version also introduces 2 conditions to verify tags with strict control. You can enforce rules on tag names and linking tags to Jira issues.

Important: don't forget to complete the upgrade steps below, as that is critical also for this feature.

Learn more about verifying tags.

New option for commit policies: "Accept existing commits without verification"

In each policy, you can now disable the verification of existing commits.

For example, when you have commits pushed to and verified on a feature branch, you may not want to verify those again when merging the feature branch to master. Previous app versions were very strict in this sense, re-verifying those existing commits, but it is not practical in some use cases. For example, if you allow committing against issues in the "In progress" status, then this condition will be overly strict at the merge time as the user story may already be in "Done" at that point.

Important: don't forget to complete the upgrade steps below, especially upgrading the hook scripts, as that is critical for this feature.

Learn more about the "Re-verify already existing commits" option.

New option for commit policies: "Accept merge commits without verification"

In each policy you can enable the verification of merge commits. Previous app versions did not verify merge commits (and this behavior remains the default), but now you can enable that.

Learn more about the "Verify merge commits" option.

New condition: "Changed paths (files) must contain issue keys from a JQL query"

This condition requires directory or file names include issue keys, effectively enforce linking paths to Jira issues.

Learn more about the "Changed paths (files) must contain issue keys from a JQL query" condition.

New option for commit conditions: "Allow additional issue keys in commit messages" (plus branch names, tag names)

For popular demand, there is a new option for the conditions that match the commit message, branch name or tag name against issue keys.

Learn more about the "Allow and ignore the issue keys that don't match the JQL" option.

Improvements

• Git branch names are now simply "feature/my-branch" (previous app versions used the refspec format like "refs/heads/feature/my-branch").
• Automatic hook script version checks are executed to find outdated hook scripts.
• Console output format was significantly extended (but also streamlined at the same time!) to display problems related to branches and tags.
• Condition configuration examples can be inserted with a click from a super-helpful floating bubble.
• New global configuration option for issue keys in branch names, tag names and paths.
• Issue keys can be entered case insensitively in commit messages ("foo-123 Fixed this bug" is equivalent with "FOO-123 Fixed this bug").
• New hook script configuration option "ssl_verify = False" allows disabling the verification of the SSL certificate when connecting to Jira over HTTPS (only recommended for testing).
• When using VCS usernames in email address format (e.g. "joe@acme.com"), its value will be used both as the user's name and as the user's email address.
• When finding multiple global configurations (corrupt data), the first one will be used and a warning will be logged.
• Rebuilt troubleshooting page with a ton of new articles.

Bugfixes

• Fixed: Only the first line of multi-line Git commit messages are processed (requires upgrading existing "pre-commit" type hook scripts on Git servers).

Upgrading from 2.4.0

This is a major app version that comes with a ton of changes, so upgrading is a bit more than a single click. Start with upgrading the app through the Universal Plugin Manager.

Then please carefully follow the guides in the next section, as there may be further steps to take. If you are unsure, just ask us any time!

Upgrading hook scripts

To take advantage of all these improvements, you absolutely need to upgrade the existing hook scripts. See the hook script upgrade guide.

If you forgot to upgrade the hook script in some repository, the apps writes this warning to the Jira log next time when a commit is received from that repository:

Outdated GIT_SERVER hook script version 1.2.3 found. Re-install the hook script in repository <my forgotten repository>

(Thus the problem does not remain hidden, and you can fix it later on the go.)

Upgrading hook scripts for Bitbucket

Bitbucket users don't use actual hook scripts to connect to Commit Policy Plugin for Jira, but they use the counter-part Bitbucket app intuitively called Commit Policy Plugin for Bitbucket.

Just remember to upgrade also that app to Commit Policy Plugin for Bitbucket 3.0.0 (released the same as Commit Policy Plugin for Jira 3.0.0). That's it.

Upgrading hook scripts for Git (excluding Bitbucket)

Simply upgrade existing hook scripts. Those should be upgraded both in the server-side repositories (by an admin) and in local clones (by the developer on their computers).

Upgrading hook scripts for Subversion

Simply upgrade existing hook scripts.

Upgrading hook scripts for Mercurial

There is no new hook script version available for Mercurial. Therefore, there is nothing to do with existing Mercurial hook scripts.

Upgrading commit policies (only for Bitbucket and Git)

If you are using Git or Bitbucket, don't forget to upgrade your existing commit policies that use branch pattern limiting. If you are not using those, you can skip this section.

If you forgot to upgrade the branch pattern in some commit policy, the apps writes this warning to the Jira log next time when that policy is evaluated:

Branch limiting pattern <refs/heads/master> (glob) in commit policy "My commit policy" rule #1 should be upgraded to avoid surprises

(Thus the problem does not remain hidden, and you can fix it later on the go.)

Upgrade follow-ups

As you've seen, we built several features to the app that will automatically write warnings to the Jira log if it finds outdated hook scripts, outdated commit policies or other resources that may need a review. A part of those will also be displayed for your developers (in their VCS client) to guarantee that the problem is recognized. We wanted to be sure that there is no repository left behind during the upgrade and every component in your system is in the most current and consistent state.

Therefore, we strongly suggest:

1. Check the Jira log regularly for a period after this particular version upgrade. Eventually, you will find repositories or policies mentioned in warnings that need little touches.
2. Tell your users that they may see eventual warnings and ask them to forward those to you. (If the warning reports an outdated local hook script, then they can upgrade that for themselves.)
3. Fix the problems reported by following the troubleshooting articles. As always, if your problem is not listed there, ask us any time .

2.4.0

This version is a compatibility release for the Jira 7.6 line.

Upgrading from 2.3.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

2.3.0

This version is a compatibility release for the Jira 7.4 line.

Upgrading from 2.2.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

2.2.0

This version is a compatibility release for the Jira 7.3 line.

Upgrading from 2.1.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

2.1.0

This version is primarily a compatibility release for the Jira 7.2 line, but also includes a couple of improvements around evaluating the "commit message must contains issue keys" condition.

Improvements

• JQL warnings and errors raised while executing the search will be displayed by the VCS client. (In previous versions, the commit was correctly rejected, but the root cause appeared only in the server logs.)
• When the JQL is empty, formally correct, but non-existing issue keys will be rejected. (In previous versions, "FOOBAR-123" was always accepted by empty JQLs. This is now accepted only if it actually exists.)

Upgrading from 2.0.1

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

2.0.1

Improvements

• JQL conditions are evaluated faster and using less memory, particularly in Jira instances with tens or thousands of hundreds of issues

Bugfixes

• No more ClassCastException is thrown during condition evaluations, in environments using Crowd for user management
• When JQL conditions are evaluated, user name is printed instead of user key (i.e. user account renames are handled in the expected way)
• VCS usernames are allowed to contain '@' characters

Upgrading from 2.0.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

2.0.0

Token-based authentication

This new authentication mode, based on security tokens instead of plain text passwords, greatly improves hook security.

Git client-side verifications (commit-msg hook)

Reject broken commits before those are actually made! This mechanism verifies the commits in the developers' clone at commit time.

Support for Bitbucket Cloud & GitHub

Verify commits locally even if the remote repository is hosted in a closed system, where you cannot configure hooks.

Hook Script Wizard

The redesigned interface makes hook script installation a breeze.

"$committer.userName" variable

This variable in JQL conditions will be replaced with the committer's username before the JQL search is executed. Example JQL: "assignee = $committer.username"

Improvements

• Execute permission "x" is auto-set for hook script files (on U*X)

Bugfixes

• VisualSVN permission problems fixed
• All condition types obey file path based scope limiting
• International character fixes on Windows (files and usernames)

Upgrading from 1.4.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

1.4.0

Support for Jira Data Center

In a clustered Jira deployment, commit policies and global settings are transparently replicated among the nodes by the app. Using the "load balanced" Jira URL in the hook scripts, you can achieve high availability in the hooks, as well. Therefore, the app fully supports Jira enterprise deployments.

Improvements

• JQL condition accepts empty an JQL string, to ease the "any valid issue key without further filtering" use case.

Bugfixes

• Textual commit condition parameters (ex: JQL queries) that contain international characters are correctly encoded.

Upgrading from 1.3.0

Just update your app version using UPM (Universal Plugin Manager, the app manager built in to Jira).

Older releases

Regarding older releases please contact us. We are happy to provide you both with the apps and the corresponding upgrade instructions.