I hope to get things out faster and make the release process simpler. So the patch version constantly receives bug fixes as well as minor improvements. Otherwise, these minor improvements will be a lot slower to be released.

Also bugfixes is very fast in OneDev (normally within 1 day).

Want to clarify that I can certainly push versions like 1dev/server:11 or 1dev/server:11.8. But the patch release may still receive minor improvements.

State changed as code fixing the issue is committed (f7d76770)

State changed as build OD-6117 is successful

This adjustment would greatly facilitate version pinning for me. Software development can often be quite complex. The integration of new features frequently brings with it the potential for novel bugs. To mitigate the risk of disruptions to my onedev instance, I prefer to bind it to a minor version (MAJOR.MINOR.BUGFIX: 11.8) rather than staying on the bleeding edge (latest). I have seen this approach in "docker.io/nextcloud/server" and find it immensely appealing.

BTW: Are there any plans to have a stable version which only includes bugfixes?

I recently changed the way i update my main onedev instance : i've always been cutting edge until 1 year ago.

Now, i have less time to handle possible update failure and i see some of these in the past release. It's a such critical tool that i stay 1 or 2 version behind, letting others "essuyer les plâtres" in french.

@robin Thanks a lot for considering this improvement.

But the patch release may still receive minor improvements.

Sounds reasonable to me. With MAJOR.MINOR-tags given I think I see a good balance between security, new features and stability.

Thanks again.