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!
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
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
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.
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.
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
The build number of the new deployment is higher than your latest build number (due to MP-524)
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 )
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)
