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.