On Tue, Dec 06, 2022 at 07:54:33PM +0500, Илья Шипицин wrote: > I recall I even promised to do something, but I did not :-) > > automatically determine "which is latest 3.0.x" does not make much sense, > it is stable branch, very conservative. we can stick to 3.0.7, for example. > I do not expect any breaking change between 3.0.7 and 3.0.8
I recall a discussion like this indeed, couldn't find the previous thread. There was cases of broken minor release for LibreSSL for example, so it's better to stick to a release for the push CI and upgrade once the weekly CI passed. > we can move "latest" to weekly, np. as for stable branches CI, I think them > do not have to follow the same rules as development branch, we can have > different matrix for stable and development. I think we could it this way: - weekly "latest" for libreSSL, OpenSSL, whateverSSL for HAProxy master branch - git push CI with fixed version in HAProxy master > I think I got the idea. > looks like you use the same github actions for stable branches. > Indeed, at some point the master branch become a stable branch, so we inherit all of this. > either I will manage to make them different or I will stick to > 3.0.something. hopefully tomorrow IMHO it should never be "latest" anywhere else than the weekly, we don't want to be disturbed by this when pushing our code. I don't think we need a weekly for the stable branch, so it could be conditionned by a check on the version, for example only started if there is '-dev' in the version. So we should probably: - Revert "latest" to "3.0.7" in the master, and backport the patch in the previous supported branches. (as far as 2.4 I think) - Introduce "3.1.0-alpha1" to master - Introduce "latest" to weekly master -- William Lallemand
