-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reduce the release cycle? #122
Comments
I think this makes sense |
I support this idea because we have reached a moment when the new features cadence has decreased, but I think that we could try to take this fact as a good reason to ship a patch releases every month or so. I'd say that we could create more automations around the release process to simplify the patch release process. My proposal is to ship 2-3 versions per year (every 4-6 months) and a patch release automatically every month, supporting only the last 2 versions if we can achieve an easy and semi-automated release process (so actually, it0ll mean 2 patch releases per month, one per version) |
It makes sense to reduce the release cycle, but the frequency of related updates should increase, such as supporting new Kubernetes versions, patching CVE requirements, and so on. I like Jorge's idea of automatically releasing a patch every month. |
I also like the idea of JorTurFer and SpiritZhou to increase the frequency of patch releases to monthly. This might also be more in line with the policy of companies regarding patch management, which can result in more adoption. I would opt for 3 releases per year (maybe similar to Kubernetes cadence). This will relieve the burden on the maintainers, but also ensures that features and improvements do not have to wait significantly long to be released. I think this will keep contributors. I can slightly imagine that if this becomes 2 releases per year, we might miss features or improvements because the (new) contributor might not see them for another max six months and then leave it at that. |
KEDA has matured significantly over the years, so our current pace of 4 releases a year may no longer be necessary. With fewer major features in each release, I’d like to propose moving to 2–3 releases annually. This should reduce the burden on maintainers who handle the release process and lessen the update frequency for end users.
Alongside this change, we can also look into improving our overall release process, including more targeted patch releases where needed—while still being mindful not to overload our release schedule.
I’d love to hear everyone’s thoughts and suggestions on these ideas.
Thank you!
The text was updated successfully, but these errors were encountered: