# A proposed way to detect add-on version upgrades

**URL:** <https://community.developer.atlassian.com/t/a-proposed-way-to-detect-add-on-version-upgrades/9419>\
**Category:** Jira Cloud\
**Tags:** devops, upgrade, webhook, lifecycle, jira-cloud\
**Created:** [September 30, 2017, 10:23am UTC](https://community.developer.atlassian.com/t/a-proposed-way-to-detect-add-on-version-upgrades/9419 "2017-09-30T10:23:41Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![david.pinn](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/david.pinn/32/36134_2.png) [@david.pinn](https://community.developer.atlassian.com/u/david.pinn)\
**Post date:** [September 30, 2017, 10:23am UTC](https://community.developer.atlassian.com/t/a-proposed-way-to-detect-add-on-version-upgrades/9419/1 "2017-09-30T10:23:42Z")

</div>

The Marketplace detects changes to the descriptor, and automatically creates a new version of the add-on. Installations of Jira Cloud then upgrade themselves to use the new add-on version over the next ten hours or so. Cool.

When a Jira Cloud instance upgrades itself, is it the case that both the `/installed`, and the `/enabled` life-cycle webhook calls are made to the add-on?

Our add-on needs to differentiate between host applications using the old descriptor, and those that have upgraded to the new descriptor. If the new descriptor includes a URL like this:

```
/enabled?version=2.0 

```

…then maybe that’s a way for the add-on to learn that a particular Jira instance has upgraded to version 2.0.

Can you give me a sanity check on this before I spend time implementing it?

---

<div class="post-metadata">

**Author:** ![yvesriel](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/yvesriel/32/310_2.png) [@yvesriel](https://community.developer.atlassian.com/u/yvesriel)\
**Post date:** [September 30, 2017, 12:02pm UTC](https://community.developer.atlassian.com/t/a-proposed-way-to-detect-add-on-version-upgrades/9419/2 "2017-09-30T12:02:33Z")

</div>

Hi David,

There might indeed a better solution but that’s what we have been doing so far. When we make changes that could break because the customer doesn’t have the new descriptor, we make sure to add a “&version=xyz” parameter to the module’s URL. This allow us to show/hide the feature until the new descriptor was installed in the customer’s instance. So far, this approach has worked for us.

---

<div class="post-metadata">

**Author:** ![david.pinn](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/david.pinn/32/36134_2.png) [@david.pinn](https://community.developer.atlassian.com/u/david.pinn)\
**Post date:** [September 30, 2017, 12:42pm UTC](https://community.developer.atlassian.com/t/a-proposed-way-to-detect-add-on-version-upgrades/9419/3 "2017-09-30T12:42:23Z")

</div>

> [@yvesriel](#):
>
> we make sure to add a “&version=xyz” parameter to the module’s URL

Do you add it to every URL, or just the `/enabled` URL? Do you happen to know if the `/enabled` endpoint is hit when the Jira Cloud instance upgrades to the new version?

---

<div class="post-metadata">

**Author:** ![yvesriel](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/yvesriel/32/310_2.png) [@yvesriel](https://community.developer.atlassian.com/u/yvesriel)\
**Post date:** [September 30, 2017, 11:26pm UTC](https://community.developer.atlassian.com/t/a-proposed-way-to-detect-add-on-version-upgrades/9419/4 "2017-09-30T23:26:49Z")

</div>

It’s not the enabled but rather the module URL itself. So, we just update the modules impacted by the changes:

```auto
  "modules": {
    "webPanels": [
      {
        "url": "/modules/issue_webpanel?issueId={issue.id}&projectId={project.id}&issueTypeId={issuetype.id}&version=20170916",
        "location": "atl.jira.view.issue.right.context",
        "weight": 60,

```

And sorry, but I never looked if the enabled URL is hit during upgrade.

---

<div class="post-metadata">

**Author:** ![david.pinn](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/david.pinn/32/36134_2.png) [@david.pinn](https://community.developer.atlassian.com/u/david.pinn)\
**Post date:** [October 3, 2017, 8:07am UTC](https://community.developer.atlassian.com/t/a-proposed-way-to-detect-add-on-version-upgrades/9419/5 "2017-10-03T08:07:00Z")

</div>

I’ve now discovered that both the `/installed` end-point and the `/enabled` end-point are hit during automatic add-on upgrade; so there’s a convenient way to manage the introduction of new features.

---

<div class="post-metadata">

**Author:** ![yvesriel](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/yvesriel/32/310_2.png) [@yvesriel](https://community.developer.atlassian.com/u/yvesriel)\
**Post date:** [October 3, 2017, 11:14am UTC](https://community.developer.atlassian.com/t/a-proposed-way-to-detect-add-on-version-upgrades/9419/6 "2017-10-03T11:14:18Z")

</div>

That’s good news! Do you get any information that would allow you to distinguish one update from another one?

---

<div class="post-metadata">

**Author:** ![david.pinn](https://sea1.discourse-cdn.com/atlassiandeveloper/user_avatar/community.developer.atlassian.com/david.pinn/32/36134_2.png) [@david.pinn](https://community.developer.atlassian.com/u/david.pinn)\
**Post date:** [October 3, 2017, 12:57pm UTC](https://community.developer.atlassian.com/t/a-proposed-way-to-detect-add-on-version-upgrades/9419/7 "2017-10-03T12:57:46Z")

</div>

Not automatically, but the `/installed?version=x.x` trick works.