Could you please let me know why 3.27.4 after 3.28.0?

[Muthukumar-Subramaniam]

In a testing environment we are using 3.28.0. Is it bug fixes of 3.28.0?
Or patch release for 3.27.3?
We were thinking that the next release would be 3.28.1.
Does it include features from 3.28.0?

[danudey]

Hi @Muthukumar-Subramaniam, thanks for the question.

The short answer is that we currently use ghr for publishing our releases to Github, but the current version of GHR doesn't support conditionally publishing a version as latest or not. This means that, by default, every release will be marked as latest. Not ideal.

I've submitted a pull request to the project to resolve this issue, but the project maintainer hasn't responded. In the meantime, we'll likely move to using our own fork of the project so that we can mark releases as 'latest' when we choose to, rather than having 'latest' mean 'chronologically most recent'.

All that being said, the 'latest' release may not be the one you want even if the releases are tagged correctly; due to features or compatibility, you may want the 'latest' v3.27 release rather than the 'highest version number' release overall, so I would recommend against relying on 'latest' except for new installations.

I hope this answers your question. I'm going to close this up, but feel free to reopen or open a new issue if you have other questions.

Cheers!

[Muthukumar-Subramaniam]

My concern here is for the new installations, should we choose 3.28.0 or the current release marked as latest.
Just getting condused on the major release number 3.28.
For example, if we go with 3.27.4 for new installations as its marked latest, does it have bug fixes for 3.28.0?
Currently test clusters are running with 3.28.0.
Further testing for new installations should we go with 3.27.4?
Automation uses the manifest file from the calico project where we update the latest version.
https://github.com/projectcalico/calico/v3.28.0/manifests/tigera-operator.yaml

For newer installation for testing should we go with 3.27.4?