Hi Community,
Update: I edited this post to reflect the latest version of the project. It now includes Windows and macOS executables, a schema-aware configuration flow, support for Community Bundled Changes, and new Community Release Notes fields such as tags and impact rating.
I wanted to share a small open-source project I have been working on to help Atlassian admins, partners, and teams monitor Atlassian Cloud release updates in a more structured way.
GitHub repository: https://github.com/pfrancezi/atlassian-cloud-release-updater
Release for downloading exe: https://github.com/pfrancezi/atlassian-cloud-release-updater/releases/tag/v1.0.2
The project is called Atlassian Cloud Release Updater. The executable utility is published as Release Notes Sync for Jira. It is a customer-run utility that helps create and update Jira or Jira Product Discovery issues based on Atlassian release information.
Why I built this
As Atlassian Cloud continues to evolve quickly, it can be challenging for admins, partners, and customer teams to keep track of all product updates in a single place.
There are official release notes, public Community posts, product announcements, admin release management views, the public roadmap, developer changelogs, bundled release tracks, and sometimes Community articles that effectively behave like release notes, even when they are not aggregated under a single release notes channel, group, or feed.
That makes it harder to answer simple but important questions, such as:
-
What changed recently?
-
Which product is affected?
-
Is this only publicly announced, or is it already visible in my admin release management view?
-
Is the change coming soon, rolling out, or generally available?
- Is it part of the bundled release track, and when is the preview or bundled release date?
-
Was the change also mentioned in the public roadmap, a Community article, a blog post, or the developer changelog?
-
Do we need to inform internal teams, update documentation, or prepare customers?
The goal of this utility is to help teams bring those updates into a Jira-based workflow, where they can be reviewed, filtered, tracked, assigned, and discussed.
What it does
The utility can collect release information from theses sources:
-
Atlassian Community Release Notes public source
- Atlassian Community Bundled Changes public source
-
Optional Atlassian Admin private source, executed by the customer in their own environment
It then creates or updates issues in a customer-owned Jira or Jira Product Discovery project.
The idea is not to replace Atlassian’s official sources. The official source always prevails. This project is meant to help teams organize, compare, and operationalize release information in their own Jira workspace.
Why compare Community Status and Admin Change Status?
One useful part of the workflow is keeping separate fields for:
-
Community Status, based on public release information
-
Change Status, based on what is visible in the customer’s Atlassian Admin release management view
This can help teams compare public announcements with what appears to be available, rolling out, coming soon, or generally available for their own environment.
With Bundled Changes, teams can also track preview and bundled release dates when Atlassian exposes those dates through the public Bundled Changes source.
Running it from a Windows executable
The project can now be used directly from Windows executables published in GitHub Releases. This makes testing easier because users do not need to install Python or build the script locally.
There are two executable targets:
- release-notes-sync-jpd.exe, for Jira Product Discovery projects
- release-notes-sync-jira-software.exe, for Jira Software or standard Jira projects
When opened without command-line arguments, the executable starts an interactive menu. The user can configure the environment, validate the field mapping, run a dry-run, run the sync, show the current configuration, or reset it.
The configuration file is created next to the executable as release-notes-sync.config.json. It stores project settings, field mappings, source preferences, and the validated Jira field schema. It does not store Jira API tokens or the Atlassian Admin cookie. Secrets are requested only at runtime.
Running it from macOS executables
The project can now also be used directly from macOS command-line executables published in GitHub Releases. This makes testing easier for macOS users because they do not need to install Python or build the script locally.
There are two macOS ZIP packages:
release-notes-sync-macos-arm64.zip, for Apple Silicon Macsrelease-notes-sync-macos-intel.zip, for Intel Macs
Each ZIP includes two executable targets:
release-notes-sync-jpd-macos, for Jira Product Discovery projectsrelease-notes-sync-jira-software-macos, for Jira Software or standard Jira projects
When opened without command-line arguments, the executable starts an interactive menu. The user can configure the environment, validate the field mapping, run a dry-run, run the sync, show the current configuration, or reset it.
On macOS, users may need to allow the downloaded command-line executable to run because Gatekeeper can quarantine files downloaded from the internet. After extracting the ZIP, run:
xattr -dr com.apple.quarantine .
chmod +x ./release-notes-sync-jpd-macos ./release-notes-sync-jira-software-macos
The configuration file is created next to the executable as release-notes-sync.config.json. It stores project settings, field mappings, source preferences, and the validated Jira field schema. It does not store Jira API tokens or the Atlassian Admin cookie. Secrets are requested only at runtime.
Schema-aware field mapping
One important improvement is the new schema-aware configuration flow.
After the user maps Jira fields, the utility can validate the configuration against Jira and save the detected field type in the local configuration file. This helps the script send the correct payload format for each field.
For example:
- Single-select fields receive an object such as { "value": "MEDIUM" }
- Multi-select fields receive an array such as [{ "value": "MEDIUM" }]
- The native Jira Labels field receives plain strings such as ["MEDIUM", "UI"]
This also helps the tool fail earlier when a configured custom field does not exist, instead of discovering the problem only after a long sync run.
Community Release Notes updates
The public Community Release Notes source now also supports fields that recently appeared in the public API response, including tags and impact rating.
These values can be mapped to Jira custom fields or, when appropriate, to the native Jira Labels field. The script adapts the payload based on the validated field type.
Bundled Changes support
The utility now includes optional support for Atlassian Community Bundled Changes.
Bundled Changes are queried by input date. The API returns data only when a valid inputDate is provided, so the tool loads the available dates, shows them as a numbered list, and lets the user choose one date, multiple dates, a range, or all available dates.
Bundled records may include the change id, title, products, type, preview track release date, and bundled track release date. Those dates can be mapped to Jira fields and used to help teams understand when changes are expected in each release track.
The Bundled Changes source does not require authentication.
Public JPD roadmaps
In addition to the GitHub utility, I have also been building public Jira Product Discovery roadmaps to consolidate and compare Atlassian Cloud updates from multiple sources.
These roadmaps include broader tracking across sources such as:
-
Atlassian Community Release Notes
- Atlassian Community Bundled Changes
- Atlassian Admin release management data
-
Atlassian Cloud blog updates
-
Atlassian public roadmap information
-
Atlassian developer changelog updates
-
Other release-related Community articles that behave like product release notes
The goal is to provide a more operational view of Atlassian Cloud changes, especially for teams that need to understand what was announced, where it was announced, and how it relates to what they can see in their own Atlassian environment.
Public roadmap links:
If you would like to follow the roadmap or contribute, you can also request contributor access in Jira Product Discovery. Contributors can subscribe, follow updates, and create their own views depending on the access model configured for the project.
Contributor request link: https://idevsolucoes.atlassian.net/servicedesk/customer/portal/10/group/48/create/270
What this project is not
This is not an official Atlassian app.
It is not intended to replace Atlassian documentation, release notes, product announcements, public roadmaps, developer changelogs, bundled release information or admin release management.
It is also not a hosted service. The code and executables are designed to be run by the customer, in the customer’s own environment, with the customer’s own Jira project and configuration.
The optional Admin private source uses the customer’s own admin.atlassian.com browser session cookie at runtime. The cookie is not saved by the utility.
Current status
This is still an early open-source project. The current version includes:
- Jira Product Discovery support
- Jira Software support
- Windows and macOS executable flow for easier testing
- Interactive menu for configuration, validation, dry-run, and sync
- Schema-aware field mapping validation
- Field mapping documentation
- Direct execution documentation
- English and Brazilian Portuguese documentation
- Community Release Notes source
- Community tags and impact rating support
- Community Bundled Changes source
- Optional Admin private source
- Automatic creation of missing select options, when enabled and when the user has the required Jira permissions
There is still room to improve how updates are discovered, normalized, and matched, especially because release-related information can appear in different places across the Atlassian ecosystem.
Feedback welcome
I am sharing this with the Community because I believe other admins, partners, and release-focused teams may have similar challenges.
Feedback, ideas, issues, pull requests, and suggestions are very welcome.
If you already have your own way of tracking Atlassian Cloud updates internally, I would also love to hear how you are doing it.
This started as part of my own attempt to keep an “unofficially unofficial” operational view of Atlassian Cloud changes. It is still evolving, but I hope it can help others facing the same release-tracking puzzle.
