This message was deleted.

Hi @refined-area-45178, thanks for your interest in upgrading to v1.8.1! simple smile Sorry for the confusing. The upgrade isn't showing up because it hasn't been officially pushed to the upgrade responder service yet. We generally recommend waiting until it's available there to ensure a smooth transition. However, if you'd like to bypass the wait and upgrade to v1.8.1 right now, you can manually inject the version into your cluster by following these steps: 1. Download the v1.8.1 version.yaml from the GitHub releases page 2. Apply it to your cluster using

kubectl create -f version.yaml

Once the custom resource is created, you should be able to see v1.8.1 as an available upgrade.

I’d prefer to wait until the upgrade becomes officially available instead of applying a custom resource. I just wanted to clarify this, as everything has already been documented, and even a minor release has already been published. Not seeing the upgrade option simply confused me. Thanks a lot for the clarification. Do you have an estimated timeline (ETA) for when the upgrade will become available? Or is there already a defined lifecycle or rollout schedule for when updates become available after a new release?

We usually pushed the release to the upgrade responder after 2 weeks.

Hi @refined-area-45178, We do not publish to the upgrade responder to ensure there are no critical issues. So, as @billions-nightfall-29291 mentioned, we usually collect all the feedback (from the community/internal users) for around two weeks. Then we will publish to the upgrade responder. Sorry about that, but we are trying to give the stable version to the users.

I see. You mentioned that it usually takes about two weeks, but v1.8.0 was released more than two months ago. That’s why I raised this question, especially since the upgrade from v1.7.1 to v1.8.0 is still not available.

v1.8.0 was the community version. We would not publish this to the upgrade responder. So, if you want to upgrade to the community for the latest features, you need to manually create the version CRD as mentioned in the document (docs.harvesterhci.io/v1.8/upgrade/index#…). You can also find the version file by replacing the corresponding version string. (e.g. releases.rancher.com/harvester/v1.8.0/version.yaml)

One more question: did I understand correctly that all

.0

releases are community releases, while

.1

and later releases are maintained by SUSE? If so, does that mean only

.1

and later releases are offered as upgrade targets?

You can figure out yourself what versions are "offered":

curl -s -d '{"appVersion":"v1.8.1"}' <https://harvester-upgrade-responder.rancher.io/v1/checkupgrade> | jq

If it's not listed there it just means that the new version is not recommended yet. Nobody stops you from downloading the version file (and/or the image) and upgrade. Just make sure the upgrade path is supported in general.

I see. I just wanted to know whether there is a versioning convention or alignment that indicates whether a release is community-driven or not.

I'm not speaking for Suse but from experience: Usually the .0 is the only community version. All following, non-0 "patch" versions are "prod" versions. For updates this is not important, see the upgrade path at docs.harvesterhci.io/v1.8/upgrade/index . v1.8.1 is not even in the docs, but the upgrade path is clear. The "community-driven" does imho not refer to the developers, but who should test this version before using it in production.

👌 Thanks all for the clarifications.