ArtUp Release documentation

ArtUp Release for Jira Cloud · Last updated: 2026-10-21

1. Install

1. A Jira administrator installs ArtUp Release from the Atlassian Marketplace (Apps → Explore more apps).
2. Sites with up to 10 users use it free; larger sites start a trial or a subscription in Manage apps (see Licence and pricing).
3. The administrator creates the first program (section 2). Everyone else opens Apps → ArtUp Release.

ArtUp Release is coming to the Atlassian Marketplace.

2. Create a program

Programs are managed by Jira administrators on the app's administration page: in Jira settings → Apps, open ArtUp Release programs. The page is titled Manage programs and lists every program with its lead project, number of projects and the state of its matching.

1. Choose Create program.
2. Program name — any name.
3. Lead project — its versions are the source of truth. The lead cannot be changed later.
4. Member projects — a program has 2 to 100 projects, the lead included. A project can be in one program only; a project already in another program is marked “Already in program …”. Company-managed and team-managed projects both work, as the lead and as members.
5. Choose Preview matching. Nothing is changed yet.

The matching preview

Each version of the lead project is looked for in every member project by its exact name, case included.

• Found once — the version is linked to the lead version (“adopted”). The preview lists, field by field, what would change in it: Name, Description, Start date, Release date, as before → after.
• Not found — the version will be created.
• Released or archived differs from the lead — a conflict. Nothing in such a version changes unless you check Bring to lead on its row (or Bring all to lead), because releasing or unreleasing someone else's version changes the history of that project.
• Several versions have the same name in one project — that version is not linked, and the preview says so. Remove the extra ones by hand; until then the copy shows Several versions have this name.
• The app lacks permissions in a project (it needs Browse projects and Administer projects) — nothing is written there until they are granted.
• Versions that exist only in a member project are never touched.

The top line counts what will happen: Link · Create · Conflicts. The preview checks project by project (“Checked n of m projects”) and may wait for Jira's request limit (“Waiting for the Jira request limit until …”); you can apply once every project is checked.

Choose Apply and create program. Names, descriptions and dates of linked versions are brought to the lead, missing versions are created, and checked conflicts are brought to the lead. Matching runs in the background — you can leave the page; the Matching column shows “n of m projects matched”, then “Matched”. A large program can take several hours to match, because matching uses only a share of Jira's request limit.

Change or delete a program

• Edit members — add or remove projects. New members are matched by exact version name, and you see the preview before Save members. Members leaving the program lose their links and stop syncing; their versions stay as they are.
• Delete — the links between versions, the program's sync log and its release snapshots are removed and syncing stops. Versions in the lead and member projects stay as they are.
• To change the lead project, delete the program and create it again. Matching by exact name links the existing versions again, so nothing is duplicated.
• If a project is deleted in Jira, the app removes it from its program.

3. What syncs and when

The app watches the versions of lead projects only. A copy is linked to its lead version by id, not by name, so renaming a version does not break the link.

• A change to a lead version reaches the member projects usually in seconds, up to a few minutes. The time depends on Jira's own queues and on the request limit of your site.
• The app works from the current state of the lead version, not from each event, so several quick changes, or one change that Jira reports twice, are written once.
• A change made from the ArtUp Release page is written to the lead project as you and then sent to the member projects by the page itself, so it does not depend on a Jira event.
• If a copy was deleted by hand in a member project, the next change of the lead version or the next sync check creates it again.
• When Jira's request limit for the site is used up, copies wait (“Waiting to sync”) and catch up when the limit allows. A change saved from the page while Jira's queue is busy reaches the member projects at the next sync check, within an hour.

The sync checks

Two background checks compare the copies with the lead and fix any difference — a manual edit or a change whose Jira notification was lost:

• The hourly check covers versions whose lead is neither released nor archived. It also runs when the app is installed or updated.
• The daily full check covers all versions, released and archived ones included. It runs in the background within its own share of the request limit and starts again once a day.

The version page shows the last check and the number of differences found (“Last sync check: … · differences found: n”) and the time of the last full check. A check skipped because the site's request limit was used up says so and runs again within an hour. Live changes come first: the checks use only their own share of the request limit.

4. The lead wins

• If someone edits a copy by hand, the app brings it back to the lead version: the hourly check does it for unreleased versions, the daily full check for released and archived ones. A later change of the same field in the lead overwrites the copy at once.
• If a rename in the lead uses a name another version already has in a member project, that copy is not renamed and shows Name taken in this project.
• Versions that exist only in a member project are never touched.

The Sync with member projects table on a version page shows the state of each copy:

Retry queues the copy again (“Retry queued for …”). If Jira's queue is busy, the project catches up at the next sync check, within an hour. The programs list shows the number of differences of each program in the Divergences column.

5. Deleted and merged versions

Deleting or merging a version in the lead project does not delete its copies: deleting a version changes the Fix versions of its issues, and the app never does that on its own. The program page shows a box Deleted versions left copies with each deleted version and the projects that still have a copy.

1. Choose Delete copies…
2. For each project choose, under Move issues to, another version of that project, or Don't move (remove the version from issues).
3. Choose Delete copies. Only the copies are deleted; issues stay. The Result column shows Deleted for each project, or why not — for example Not allowed: you need Administer projects in this project. Send again repeats what is not done yet.

6. The ArtUp Release page

Open Apps → ArtUp Release. Programs lists the programs whose lead project you can browse, with the lead project, the number of projects, the next unreleased version and the number of differences (Divergences).

• A program lists the versions of its lead project, like Jira's Releases page: status (Released, Unreleased, Overdue, Archived), start date and release date. Create version creates a version in the lead project; it is copied to every member project.
• A version shows its dates, Readiness, Sync with member projects, Release notes and, once released, the Release snapshot and Changes since the release.
• Edit, Release, Unrelease, Archive and Unarchive are on the version page for people with the Administer projects permission in the lead project. The change is saved to the lead project as you, then copied to the member projects (“Saved. The member projects are being updated.”).
• Jira's own rules apply: a name the lead project already has is refused (“A version with this name already exists in the lead project.”), and so is a start date after the release date.

7. Readiness

For a program version the app counts the issues of the lead version and of all its copies: Issues: n · To Do · In Progress · Done, by status category, with a progress bar and a table by project (To Do, In Progress, Done, Total, Progress).

• Open in search opens all the issues of the release in Jira's issue navigator, using the ids of the lead version and its copies.
• The numbers are read as you: issues you cannot see are not counted, and a project you cannot see appears as Project you can't see with No access instead of numbers.
• If Jira takes too long to answer, the page says the numbers are incomplete; reload to count again.

8. Release notes

• Grouping and status categories: group by Issue type (the default) or Project, and choose the status categories to include (Done by default).
• Source: an unreleased version uses the current issues of the version and its copies; a released version uses the snapshot taken at release (“Built from the snapshot taken at release on …”), so its notes do not change when issues are moved or reclassified later.
• Formats: Copy Markdown, Download Markdown, Download Word (.docx) and Download PDF. The Word and PDF layout is built into the app and made in your browser; the headings follow your Jira language.
• Contents: the program, the version, its dates and status, a summary by project (issues and Done), and per group a table of issue key, summary, type and project.

9. Release snapshot and changes since the release

• When a program version is released, the app saves a snapshot of its issues across all projects: issue key, project, type, summary and status category. Releasing it again after an unrelease takes a new snapshot; the old ones are kept, and the Snapshot list lets you choose one.
• The snapshot is taken as the app, so it is complete whoever pressed Release. It is shown as you: rows of issues you cannot see now are hidden, and the page says how many (“Hidden: n issues of the snapshot that you can't see now”).
• If the app could not read a project when the snapshot was taken, the snapshot is marked Incomplete and names the projects.
• A version released before the app was installed has no snapshot; its notes use the current issues.
• Changes since the release compares the snapshot with today: issues added, removed, or moved to another status category (before → after). Download CSV exports the comparison.

10. Permissions

11. Limits

• 2 to 100 projects per program, the lead included; a project belongs to one program only.
• The lead project of a program cannot be changed in this version; delete the program and create it again.
• Only versions sync: no components, project categories or version order. The sync never deletes a version and never changes issues.
• Word and PDF release notes use one built-in layout; there are no custom templates and no publishing to Confluence.
• The sync checks use their own share of Jira's request limit. A program too large for that share — a lead project with a very large number of versions for the daily full check, or too many unreleased versions for the hourly check — is skipped by that check. In this version the page does not name a skipped program. Its copies still follow every change in the lead project; only a copy edited by hand, or a change whose notification Jira lost, is not brought back by the skipped check.
• Jira Cloud only; Jira Data Center is not supported. Company-managed and team-managed projects both work.

12. Licence and pricing

• Free for sites with up to 10 users. Larger sites subscribe through the Atlassian Marketplace, per user and billed by Atlassian: $100 per month for 200 users.
• Without an active licence the pages show “ArtUp Release needs an active license”, and the app makes no new syncs and no new snapshots. Versions and links already created stay as they are. When the licence is back, the sync checks catch up with what was missed.

13. Data handling and uninstall

ArtUp Release is a Forge app with no external servers and no outbound calls. It reads project versions, the project list, the issues of a version (key, project, type, summary, status category) and project permissions. It stores in Forge SQL and Forge storage: programs (name and project ids), links between versions with the last synced name, description, dates and flags, a sync log of the newest 1,000 entries per program, release snapshots (issue id and key, project id, type, summary, status category), and matching previews for 24 hours. It stores no issue descriptions, comments, attachments, user names or account ids. Scopes: read:jira-work, manage:jira-project (project versions only) and storage:app. Details: Privacy Policy and Security.

Uninstall: the versions the app created or changed are ordinary Jira versions and stay in your projects with their issues. Atlassian deletes the app's Forge storage and SQL data according to Atlassian's data retention policy.

14. Languages and support

The app pages follow each user's Jira language (26 languages) and the light or dark theme. Word and PDF headings are in the language of the user who downloads them.

Questions, bug reports and feature requests: [email protected]. Please include your Jira site URL, the program and version, the state or message you saw and the project keys. See Support.