Recommendation on updating the add-in

[vtiti]

Hi. T

his page describes how to update my submission to the AppSource.
It would be nice if there were some words, how should I handle the submission if I want to update my add-in.

Here is an example scenario:
We submitted an add-in successfully. Then we implement something cool, but it needs to change something in the manifest. When we submit the new manifest it contains the url to the add-in code. So it is necessary to update the addin code before the submission, which means the live audience got the new add-in before the approval.
What is the good/recommended way to upgrade the add-in?

Another thing not clean for me:
The submission form has a version field, which gets the value from the manifest. If we updating the add-in we may change the version which may be shown in the add-in UI. We may update something small, maybe something big.
What is the recommended process to update the version in the manifest?

Thanks.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: 62273393-b7a5-bd0a-84d7-42055370c860
• Version Independent ID: 27aa3fc1-e883-5076-234f-e158eff79c0f
• Content: Update or unpublish your add-in in Seller Dashboard
• Content Source: docs/update-unpublish-and-view-metrics.md
• Product: office
• GitHub Login: @o365devx
• Microsoft Alias: o365devx

[Lauragra]

Thanks for reaching out. @PhilSmail , can you take a look please?

[PhilSmail]

Apologies. Just seeing this now
RE the upgrade the typical way developers deal with this is versioning the URL in the manifest. If you're old version is http://mysite/v1.0 and your new one is http://mysite/v2.0 then your v2.0 URL can provide the new experience before it goes public

Re version numbers. That's an interesting question but it's ultiamtely up to you. The versioning follows the format A.B.C.D
A for big changes, B for medium changes, C for bug fixes etc. D isn't normally used