ACE Plugin Versions BaseUrl change will trigger a re-review process

Jira Development Jira Cloud
, ,
1

Hi,

Since September of last Year changing the plugin base url will cause a manual re-review process, where atlassian will create a ticket and ask us if anything major did change.
Re-Review Announcement
We currently have a separate version running for our releases and each version has a different base url, which will cause this manual re-review process with a delay of around a week. While that is not good, it does a major issue when we will try to move to Connect On Forge. The reason for the issue is that any change to the base url there will cause a major release and as a result every admin would need to update manually.

Today I decided to work around this issue by changing the base url in the atlassian-connect.json so that it no longer contains the version.

Example Old

"baseUrl": "https://esu.aptis.cloud/epicSumUp2/v20/",

New

"baseUrl": "https://esu.aptis.cloud/epicSumUp2/",

After a few hours I must say that for me it seems that Atlassian-Connect-Express does not support to have multiple versions of an App at all. Why is that?
All of the default endpoints of ACE are registered based on the baseUrl in the descriptor without any chance to intercept (as far as I could see in the source code). This include the following endpoints

  • /atlassian-connect.json
  • /installed
    etc.

Sure I know of a lot of market place partners that will just replace the ACE app as most of the errors will be resolved within a few hours. Most of the time not a lot of customers will see errors as a result (they don’t come a cross the relevant part of the app or it’s released during times where a lot of users are not working). But Atlassian sure makes it hard market place vendor if they want to prevent these types of Errors.
Why is it such a pain to get a working release process without the risk of customers getting errors because the atlassian-connect.json and the frontend code is out of sync?

Am I missing something basic here? It’s a bit frustrating to lose a day while figuring out how we are supposed to develop addons and a once perfectly fine release process is no longer supported and the alternative way would leave our customers with potential error messages, require manual update for every hotfix version or are delayed by a week

2

I prefer the lack of “versioning” in Connect. It means you can instantly deploy fixes/updates into production multiple times per day, and your only time delay is browser caching.

Most modern build pipelines (Cloudflare, Vercel, Netlify etc) automatically create deployment preview URLs and one-click deployment rollback. That’s where you should be moving your particular versioning/staging requirements to.

Whereas versioning in Forge is an absolute nightmare. The Forge platform is not production-ready despite what they say, so they’re constantly changing things such as scope names. That creates new versions which require manual admin updates. Admins don’t manually update apps, so Atlassian will spam your inbox with errors that were fixed literally years ago. It’s an incredibly anti-agile pattern.

3

It would be fine if connect would work fine if the versioning of connect would really work without versioning, but there is a forced versioning of the atlassian-connect.json which causes issues.
I tried it out with a dev version on one of our latest releases:

  • New Frontend User Interaction that opens a dialog
  • Dialog Content is within a new URL Endpoint which is described in atlassian-connect.json

The customer will see an error when trying to open the new dialog. This is not something I would like to risk or even think about before I release a version.

The forge stuff also sounds like something that needs to be adressed. Major Updates (Manual Updates) should be something that happens rarely. Even for scope changes I would prefer it if you could define optional scopes (and the ability to check them) to prevent a manual update where the customer sits for all eternity because he is not aware that cloud addons may need an update