Repository navigation
Replies: 10 comments 11 replies
|
We should go for either LTS or latest-1, not both. For LTS we will most likely need to limit it to a single LTS (with some overlap). For example at the moment we can support 26.6, but not 26.4 as that is based on an older version of Quarkus that is no longer supported in the community. We also need to set some rules/guidance of the expectations of the support level for previous releases. We won't be able to backport all fixes and CVEs to all supported versions, the older the version the more strict we'll need to be in terms of prioritising what bugs and CVEs gets backported. |
|
Why can't we do both? They address different problems, one is making it easier to use and update between LTS versions and the other to update from the previous to the current version. |
|
That boils down to effort and capacity. At least I would not start with two options, as we're then going from supporting 1 release to supporting 3 releases. I would think that latest-1 would serve the community best; as currently we support only the latest release, which requires everyone to upgrade on the day, which is not good at all, to receive bug and CVE fixes. By supporting latest-1 we're extending on that. LTS is a completely different thing in my head. That also then opens the question of an LTS-1 support, bringing us to 4 supported releases if we also do latest-1. |
|
Can you clarify that |
|
latest-1 would be previous x.y release; if 26.8 is current then it would be 26.7; if 27.0 is current then it would be 26.8 |
|
I personally would appreciate a latest-1 approach. Currently once a new minor version is released with CVEs fixed along other features, you always have the choice updating to latest version fixing the CVEs, but potentially running into regression issues, especially if we are talking about the x.x.0 versions or you temporarily accept the CVE in your code until the latest version has stabilized. Or you start backporting, building the image on your own. |
|
👍 for the LTS approach. What would need to be implemented in order to do this?
|
|
Hi, I’m very much in favor of this proposal. For us, the main benefit would be being able to follow a gradual upgrade path such as "26.4.x → 26.5.x → 26.6.x → 26.7.x", rather than having to jump directly from one LTS to the next. Each Keycloak upgrade requires a significant amount of cross-system validation, including integration/regression testing and performance testing. We therefore don’t necessarily want to move immediately to the next LTS, which can still be relatively young when we start our upgrade process, especially if the previous minor version is quickly dropped from maintenance. The increasing pace at which CVEs are being discovered and fixed makes this even more challenging: we need to keep our Keycloak version reasonably recent from a security perspective, while still having enough time to properly validate each upgrade. Keeping the previous uneven release maintained for a transition period would give us much more flexibility and would make incremental upgrades a much more realistic option. I also strongly support making the LTS tags official releases. It would make the maintenance status much clearer for downstream users and security tooling. |
|
It would be amazing if we could count on getting a release at the end of a week, any time you've resolved a High or Critical CVE. |
|
Can you elaborate? Do you mean a fixed release date/cadence? |
|
Lets say that 26.7.1 has a vulnerability that has been resolved in main. I'm not looking to cause un-needed releases ... only if they resolve a problem. |
|
That's orthogonal to this discussion; but to answer that - we push patch releases on demand; where the decision to push a release is triggered based on bugs and CVEs. For third-party dependencies we can not push a release every-time there is a new CVE fixed, but rather we do it based on the severity. |
|
We have 27 release coming up in the not too distant future. As it's a major release we really should provide some overlap between 27 and 26 series. That would be a good time to try out latest-1 approach, supporting the latest 26.x until 27.1 is released. |
|
Appreciate for latest-1 approach. Assuming 27.x release is next one, will all the bug and CVE fixes will be in 26.7.3. or only selective fixes goes in to latest-1 release. |
|
Probably backporting each and every bug or security issue is too much effort. I would appreciate if at least critical CVEs would be backported. |
|
Any plans for latest-1 would only be applicable to future release, not past releases, so 26.7 is not considered. Most likely latest-1 would be a Keycloak 27.x thing. Supporting 26.x (26.8) overlapping with 27.x is a separate thing. We'll make sure there is some overlap between major releases, but that won't fit directly into latest-1. |
|
Just go aware of #51833, one of these rare critical CVEs that really impact a lot of people and it is really a pain that though the backport 26.6.x exists it is not published as a release. |
|
Sure, that is part of using on a non-supported release (which 26.6.x became the second 26.7.x was released), and hence the main motivation for this discussion in the first place. |
|
I am also in favor of the latest-1 idea. We use a provider of custom keycloak extensions who build their versions from the source tags, so we can't just skip to 26.7.x and instead need to build our own releases instead of using a published version. (Similar issue as here) |
|
I'd like to get some feedback from the community on the preferred option, please vote here: #52655 |
|
Thanks for all the comments, we are committed to finding a solution to this so please follow #52656 and comment there. Also, see my previous comment on voting for your preferred option. |
Uh oh!
There was an error while loading. Please reload this page.
Currently, Keycloak releases patch versions of the latest release only. Additionally, it provides backports of important bug fixes to the release branches of the latest two even numbered minor versions. These versions are also regularly tagged but no releases are created. I guess a lot of people have found out about this and are using these "LTS" branches to create their own releases based on these tags (as we do).
I would like to suggest the following:
This should be mostly automated so there shouldn't be much additional effort. It would save the community the effort to create their own releases. Also security scanning tools should have an easier time to recognise which versions fix which vulnerabilities so security processes need less manual curation. Last but not least, it would also be nice in the Keycloak Terraform provider to use the latest LTS versions for testing.
The reasoning is that currently, when a new even version is released, the previous version immediately drops out of maintenance and people need to update immediately to the new version. Since this might be difficult in practice, people are incentivised to go for the LTS versions of Keycloak because when updating, the previous LTS will always be maintained for some time. This means less people using the newest Keycloak features and less feedback for the project.
On the downside, there is some additional effort required for this as backports have to be created for three versions always. Currently, backports are created for three versions only when the latest version is uneven (e.g. 26.7 is current, backports are created for
release/26.7,release/26.6andrelease/26.4). Otherwise backports are created for two versions (when 26.6 was current, backports had to be created forrelease/26.6andrelease/26.4).I am curious what the community and the other maintainers think about this. Please give feedback or a thumbs up if you like the idea.
All reactions