Sharing an open-source utility to help track Atlassian Cloud release updates in Jira

[#1]

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:

1. Atlassian Community Release Notes public source

2. Atlassian Community Bundled Changes public source

3. 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 Macs
• release-notes-sync-macos-intel.zip, for Intel Macs

Each ZIP includes two executable targets:

• release-notes-sync-jpd-macos, for Jira Product Discovery projects
• release-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:

• The Unofficially Unofficial Atlassian Cloud Changes Roadmap: https://idevsolucoes.atlassian.net/jira/discovery/share/views/f380bf69-8b83-4e25-a323-c39d3a7bdb0b
• Public Roadmap:   https://idevsolucoes.atlassian.net/jira/discovery/share/views/044144e7-af32-48b1-b1a5-aa777f50ded7
• Developer Changelog Tracking: https://idevsolucoes.atlassian.net/jira/discovery/share/views/dd8b0096-9b38-445a-a822-2d2dbfb5915e

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.

[Darryl Lee]

Yaaaaas, this is awesome. Most especially, thank you for finding the APIs that back the new Community Release Notes!

# Public Community Release Notes API.
COMMUNITY_API_URL = "https://community.atlassian.com/gateway/api/public/app-updates/v1/changes"
COMMUNITY_DETAIL_URL_TEMPLATE = "https://community.atlassian.com/gateway/api/public/app-updates/v1/change-details/{change_id}"

One thing these APIs show that are inexplicably missing from the UI are:

<firstPublishedAt>2026-06-29T18:15:30.042Z</firstPublishedAt>

And:

<releaseStartDate>2026-06-29</releaseStartDate>

@Bill Sheboy, @Dirk Ronsmans, @Mykenna Cepek, @Josh and others pointed out the lack of useful dates when Release notes on Atlassian Community were first introduced.

@Patricia Francezi_iDev_ you've built an amazing tool, and more importantly, you've shared it AND the code. Thank you so much!!

[Patricia Francezi_iDev_]

@Darryl Lee Im working on this since March, if Im not wrong. When I felt confident that this is a good workflow I shared. 

The main reason is compare with my instance or customer instances. Its not easy to get the news, and also check the feature in UI, and also, and also.... yeah, we need to do ourselves 

If you want the developer changes, I can improve to share.... 

Feedback, and suggestions are valuable! thanks for your support!!!

[Susan Waldrip]

@Patricia Francezi_iDev_, this is a GREAT resource! Thank you for all the work you've done and for sharing it, I hope you get a lot of helpful suggestions and contributions. Several people are trying to fill this gap in the Community ( @Darryl Lee , @Bryan Guffey , @Jimmy Seddon and others) so this is a wonderful addition towards that goal. For those of us using Standard plans, these tools are so helpful because we  don't have a periodic release track capability and changes just show up so keeping up with what's coming is vital. So thanks again, Patricia, great work!

I'm thinking this app would be a great basis/resource for someone knowledgeable in API to teach an "API for Dummies" course, I'd love to set up and use this app -- anyone interested? 😊 

[Patricia Francezi_iDev_]

@Susan Waldrip do you want the course or provide it? 

If you need to setup the tool, you just need to run the python script, it asks you for your OrgID, your instance etc, and it will work with this definition, so no, you dont need to know the apis to run the helper. 

If you use community slack find me there. We may think about the API for dummies together.  I love this, nowadays we need to know the tool (the apis), but not the codes. lol 

[Patricia Francezi_iDev_]

Hey all, I have updates in https://github.com/pfrancezi/atlassian-cloud-release-updater/releases/tag/v1.0.1

Changelog

1.0.1

Added

• Added validate-config command.

• Added cached Jira field schema in release-notes-sync.config.json under fieldSchema.
• Added dynamic payload formatting based on real Jira field type:
  • single-select -> { "value": "X" }
  • multi-select -> [{ "value": "X" }]
  • native Labels -> ["X"]
• Added special handling for Jira's native labels field.
• Added hard-stop configuration errors for missing configured custom fields.
• Added optional Community Bundled Changes source.
• Added Bundled Changes input date picker support with second-Tuesday fallback dates.
• Added support for Community Release Notes tags and impactRating.
• Added documentation for configuration validation, bundled changes, test procedures, flow/status rules, and field mapping.
• Added PowerShell helper scripts for configure, validate, and common dry-run scenarios.

Changed

• postDate was renamed to adminPostDate in configuration and documentation.
• Admin/private values remain separated from Community/Bundled values:
  • Admin type -> Admin Change Type
  • Community/Bundled type -> Community Change Type
  • Admin postDate -> Admin Post Date
  • Community firstPublishedAt -> Community First Published and calculated week fields
• Bundled Changes no longer asks for or sends a product filter. It uses inputDate only.
• Community Impact Rating is no longer hardcoded as single-select or multi-select. The cached Jira schema decides the payload format.

Fixed

• Fixed Community first-published date loss during enrichment when details did not repeat list fields.
• Fixed native Labels payload format.
• Fixed auto-option creation so native Labels and non-select fields do not call custom field context endpoints.
• Fixed field context 404 handling for invalid customfield_xxxxx mappings.
• Fixed option creation request method.
• Fixed duplicate Bundled Preview Date assignment in create payload.

Security and privacy

• Jira API tokens and Atlassian Admin cookies are still requested at runtime and are not saved to configuration.
• Field schema cache contains field ids, field names, and field types only. It does not contain credentials or issue data.

[Patricia Francezi_iDev_]

Updates: 

https://github.com/pfrancezi/atlassian-cloud-release-updater/releases/tag/v1.0.2

1.0.2

Added

• Added macOS command-line executable distribution for Marketplace review and customer-run testing.
• Added Apple Silicon and Intel macOS build artifacts:
  • release-notes-sync-macos-arm64.zip
  • release-notes-sync-macos-intel.zip
• Added macOS PyInstaller workflow to build onefile CLI executables for both project modes:
  • release-notes-sync-jpd-macos
  • release-notes-sync-jira-software-macos
• Added ad-hoc macOS code signing during the build workflow.
• Added workflow support for uploading tested macOS ZIP files directly to an existing GitHub Release by providing release_tag.
• Added macOS direct execution guides in English and Portuguese:
  • README_DIRECT_EXECUTION_MACOS.md
  • README_DIRECT_EXECUTION_MACOS.pt-BR.md
• Added macOS executable testing guide for Marketplace reviewers:
  • docs/TESTING_MACOS.md
• Added macOS packaging and release workflow documentation:
  • docs/PACKAGING_MACOS.md

Changed

• Updated the main English and Portuguese READMEs to point to the Windows and macOS execution guides.
• Kept Windows direct execution documentation separate from macOS direct execution documentation.
• Updated the Windows testing guide to point reviewers to the dedicated macOS testing guide.
• Clarified that macOS builds are command-line executables, not .app bundles.
• Clarified architecture selection for macOS downloads:
  • arm64 for Apple Silicon Macs
  • x86_64 for Intel Macs

Documentation

• Documented macOS Gatekeeper and quarantine troubleshooting with:
  • xattr -dr com.apple.quarantine .
  • chmod +x ./release-notes-sync-jpd-macos ./release-notes-sync-jira-software-macos
• Documented how reviewers should download macOS ZIP files from GitHub Releases and run configure, validate-config, dry-run, and optional sync.
• Moved maintainer-only build and release flow details out of the reviewer testing guide and into docs/PACKAGING_MACOS.md.

Security and privacy

• Jira API tokens and Atlassian Admin cookies remain runtime-only.
• macOS packaging does not add credential storage or any hosted backend.
• The local configuration file still stores only project settings, field mappings, source preferences, and validated Jira field schema.