Avoid upgrading from v5.3.1 on Windows #25135
Conversation
Added a condition in the Windows WiX bundle that prevents upgrades from v5.3.1 and recommend the user to upgrade to v5.3.2 first. That's needed because version 5.3.1 of the installer had a bug that got patched in v5.3.2 only. c.f. containers#24735 Signed-off-by: Mario Loriedo <[email protected]>
openshift-ci
bot
added
release-note-none
do-not-merge/work-in-progress
openshift-ci
bot
removed
the
do-not-merge/work-in-progress
|
Timeout on one of the applehv tests with the new 45 minute timeout. |
|
LGTM |
|
all tests are good @containers/podman-maintainers PTAL |
|
I cannot really review any of the changes. |
| # with | ||
| # `Get-Latest-Podman-Setup-From-GitHub` | ||
| $env:PREV_SETUP_EXE_PATH = Get-Podman-Setup-From-GitHub -version "tags/v5.3.0" | ||
| $env:PREV_SETUP_EXE_PATH = Get-Latest-Podman-Setup-From-GitHub |
There was a problem hiding this comment.
I still like to insist that is is fundamentally flawed approach. We should NEVER depend on rolling targets as this starts breaking on random PRs and block any development in the meantime. #24653
The proper approach should be to hard docs the version and then update said version after each release. Yes annoying but that can be automated with renovate.
The reason why this is so important is release branches, if we always pull the latest here it means a release branch, i.e. old 4.9 branch that was used for a bit, will then pull the latest and that might fail the installer update testing because the code there is much older. Now with our current releases and just supporting the latest release there will not be often cases where this might play a role but it can bite us in the future.
There was a problem hiding this comment.
We are protected against problems like #24653 because we are now testing upgrades from the main branch (in addition to testing upgrades from the release branch). This allows us to detect problems much earlier.
You are right in general, but I am trying to be pragmatic. We aren't particularly good at updating versions in Windows-specific code.
There was a problem hiding this comment.
We aren't particularly good at updating versions
Right which is why my advocating for automating these via renovate.
Or maybe do not hard code the same version in many places and use something like
grep github.com/containers/gvisor-tap-vsock go.mod | cut -d" " -f2 or however that would be done in powershell.
But yeah I am fine to block on on that, we clearly want this in 5.4 so I am fine with doing this for now.
But I Really think long term this is not sustainable
@Luap99 thank you for the review and I have updated the description. Your guess is correct. This is a follow-up to #25021 to avoid a regression of #24735 for someone who tries to upgrade from v5.3.1 to 5.4.x. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: l0rd, Luap99 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
This PR adds a condition in the Windows WiX bundle that prevents upgrades from v5.3.1 and recommends the user to upgrade to v5.3.2 first.
Version 5.3.1 of the installer had a bug that got patched in v5.3.x. The patch won't be included in the installer for v5.4.0 (see here for details), and we can't allow direct upgrades from v5.3.1 to v5.4.x anymore.
Does this PR introduce a user-facing change?