@stianst Thank you for your feedback, it’s much appreciated.

Even with automated testing and roll-outs in place, I believe it remains essential to actively monitor new versions after deployment for any potential impact, and to take prompt action if needed. Given Keycloak’s global user base, it would be beneficial to choose a release day that allows developers in most regions at least a day or two to monitor and respond effectively.

All patches, whether they address bugs or security issues, carry value. That said, I agree that there should not be a release simply for the sake of releasing. One possible approach is to enhance the automated weekly patch process with a threshold check, for example, requiring at least two patches before automatically tagging and releasing. If the threshold is not met, that week’s patch release version could be skipped. The process should also allow for manual intervention, enabling a patch release outside the regular schedule when an urgent fix is needed and cannot wait for the next planned release.

Sure, you need to monitor after roll-out, but you need to monitor your environment regardless. All I'm saying is there are folks that have automated all of this, that can roll out releases quickly, and there are folks that haven't and require more manual intervention. For the first group it matters less how frequent the releases are, but for the others you want to upgrade when necessary and not on a regular cadence.

On the contrary I believe that in most cases by releasing on-demand and not a fixed schedule we actually give users more time to update. The alternative is we wait for a fixed release schedule, which results in less time for people to upgrade.

Let's consider a few scenarios.

There is a significant bug that is causing real trouble. By releasing on demand we give people more time to upgrade, and those that are not affected can simply wait without any problems.

Similarly, for CVEs in third party dependencies these are in the majority cases already public by the time we are aware of them. The quicker release again the more time we provide to people to upgrade.

Final scenario is embargoed issues; these are actually more difficult to deal with and we simply can't deal with these on a fixed release schedule as we are not always in control of the embargo date, and have to coordinate with others around this. A fixed release schedule would in many cases resulting in the inability to deliver a fix on the date the CVE is made public, which is not a good thing. What we do instead is we often release a patch release with bug fixes as soon as we are made aware of any such CVEs, that is so when we eventually release the CVE fixes it comes in a patch release with as few fixes as possible, in the majority of cases these release only contain fixes for CVEs and nothing else.

Essentially what I'm saying is release on demand and update on demand.

What we could perhaps do though is to give heads-up on when a release is planned; sometimes we plan the release the day before, but more commonly we plan it in a week or so. I'm happy to make that public. Including when we know there are embargoed CVEs coming. We can't provide the details for the specific CVEs, but we can give heads up that such a release is coming and an estimate on what day it will be released.

@stianst Thank you again for your thoughtful and detailed response, I really appreciate the time and clarity you’ve provided so far.

I feel there may be a bit of misalignment in our perspectives, and I’d like to understand your viewpoint better. I’m not entirely sure which areas we differ on, so I thought it might help if I asked a few focused questions:

• My understanding is that if Keycloak consumers adopt security patches or bug fixes earlier, it could reduce the window of opportunity for potential attackers and limit the number of end-users affected. Would you agree with this view, or do you see it differently?

• My assumption is that external contributors of Keycloak patches are generally motivated to have their fixes released sooner rather than later. Does that align with your experience?

• I also understand that Keycloak consumers aren’t obligated to update to every patch version, even if patches are released more frequently. Is that correct?

• Would you agree that Keycloak release and update/deployment cycles could be managed independently?

Just to clarify, my proposal isn’t intended to remove the on-demand release process. Rather, I’m suggesting that it could remain in place alongside an automated release process. The automated approach could exclude any on-demand or embargoed issues by using labels or commit/PR counts/data. In cases with an embargoed label, the on-demand release would naturally take priority over the automated schedule/release.

I’d really value your thoughts on these points, and I hope this helps us get closer to a shared understanding.

What we could perhaps do though is to give heads-up on when a release is planned; sometimes we plan the release the day before, but more commonly we plan it in a week or so. I'm happy to make that public. Including when we know there are embargoed CVEs coming. We can't provide the details for the specific CVEs, but we can give heads up that such a release is coming and an estimate on what day it will be released.

@stianst announcements of planned releases in some form would be very helpful and would aid in our internal discussions about timing of deployments / upgrades. Is this something that could be actioned soon?

Major or minor releases are announced on https://github.com/keycloak/keycloak/milestones; as previously mentioned patch releases are done on-demand, and usually only with a few days (or some day) timelaps between planning to do the release and doing the release. There really would be not much value in us announcing that "tomorrow we're doing a patch release"