Bug with backporting of minor version updates to outdated versions

Recently we followed the backporting documentation by atlassian (https://developer.atlassian.com/platform/forge/cli-reference/deploy/#backporting) to release updates to outdated versions in order to get rid of invocation errors. At the same time, we also added a nice banner to inform our customers to update.

Imagine our surprise when we then got a support ticket “We see the banner, but no version which is more recent”. It turns out that a fresh install of our app installs the latest released version, so in this instance our backported release of an outdated version!

So we are now releasing another version on top (with the hope that this will fix it), but this was definitely a surprise to us!

22 Likes

@AdamMoore :open_mouth:

3 Likes

Nice! That was a known issue with Marketplace for Data Center releases. Good to see Atlassian is keeping the tradition alive. @marton.kelemen

6 Likes

Did you deploy a git hash with its parent being your last (backport) major version git hash? I’m curious if this would work? I’m looking into backporting a fix to a version before a major version upgrade which introduces app:licensing:enabled :innocent:

Pretty much. Each time we release a new forge version, we label it in our git commit history with the date, which made finding the right commit quite simple.

We then did the changes we wanted to, and then released a backported version using

forge deploy --major-version [version] --verbose -e production

This is documented here: https://developer.atlassian.com/platform/forge/cli-reference/deploy/#backporting

However, right after you have done this, you should release an update to your latest major version again - otherwise your backported version is now your most recent version. :melting_face:

1 Like

Can someone from Atlassian comment on this? If new installs aren’t using the latest version (as per semver) then that is pretty wild/bad.

1 Like

When we asked this in a support ticket, we were told ‘this behaviour is expected, Document describes this behavior.’. So @istvanverhas is absolutely right… traditions are kept alive apparantly.

1 Like

After internal discussion this behavior is reported as bug https://jira.atlassian.com/browse/MP-524.

Workaround

Whenever a backported update is released, also release a new version of your latest major version.

This will keep the update button available, since the latest major version will always appear at the top of the list.

3 Likes

My support champion confirmed the following:

  1. Deploy the backport version to Forge platform with a major version lower than the current major version. In our case the backport version was free, the latest major version is paid LOL
  2. The build number of the new deployment is higher than your latest build number (due to MP-524)
  3. A ECOHELP ticket is generated - Ask the ECOHELP team immediately to reject the backport version on the MP in order to avoid unintended manifest roll-back on the ‘latest’ version on MP (@Anja )
  4. Rest assured that your recently deployed the backport version is rolled out correctly to all instances that are still on the lower major version. It doesn’t seem to matter that the MP version is rejected.

Lower major version 5 after backport deploy (5.5.0)

Rejected lower minor versions on MP

1 Like

Do we reckon Atlassian sorts out how versioning works on Forge before or after they pull the plug on Connect?

Ridiculous as always.

2 Likes