Andrew Clayton

> And exposing that check in the .github will allow a PR author to > change that as a part of PR... Well the check wouldn't be in the github...

I'm afraid this is also wrong. We will end up with the three _bugfix_ commits that are already on master, duplicated on master again. If you remember, we had this...

> I remember this and I still think that crafting this commit manually > is greater evil than a mere merge > (since I don't see anything bad in duplicated...

For comparison here's the 1.29.1 back-merge... ``` * | 814815a3 Merged with the 1.29 branch. |\| | * d5382aeb Unit 1.29.1 release. | * 0af1253c (tag: 1.29.1) Generated Dockerfiles for...

Hi Alex, > alx@debian:~/src/nginx/unit/master$ git describe --contains bbeccabe > fatal: cannot describe 'bbeccabe0a40c689466d97570e44829e3c1ddb3b' Hmm, that seems to work for me... ``` $ git --version git version 2.44.0 $ git describe...

> This leave us with inconsistent CHANGES > https://github.com/nginx/unit/blob/master/CHANGES at least, that was > reported by @tippexs and @Jcahilltorre I'm evermore convinced that the changelog files should simply be _ignored_...

I'm 50/50 on whether we should list bugfix releases in the master changelog. Then again I'm generally doubtful about having the changelog, in the repository at least, at all... I...

> CHANGES https://github.com/nginx/unit/blob/master/CHANGES file used as > a reference during release as a source of recent changes. Therefore, > the fact of the release should be noted in the master...

It seems to break as soon as it hits anything that isn't [0-9.] in the version.

On Fri, 24 Nov 2023 07:19:08 -0800 Timo Stark ***@***.***> wrote: > I am flexible what exactly we should do here but not beeing able to building a Container Image...