I find MIN_BUILDER_VERSION configuration confusing every time I am looking at it. First, it has a different format than our real version, so a stable release is e.g. 0.49-1 and we configure 0.49.1.dev to override it. Furthermore, Tito produces a package with 0.49-1.git.62.fc3afd4 which is less than 0.49.1.dev.

$ rpmdev-vercmp 0.49-1 0.49.1.dev
0.49-1 < 0.49.1.dev

$ rpmdev-vercmp 0.49-1.git.62.fc3afd4 0.49.1.dev
0.49-1.git.62.fc3afd4 < 0.49.1.dev

So I don't see any way to bump the MIN_BUILDER_VERSION without requiring to immediately release a new copr-rpmbuld package. That means, that within PR I need to bump the MIN_BUILDER_VERSION, which will temporarily break the PR for me because my copr-rpmmbuild version won't be sufficient and after merging the PR, I will release its new version to get it working again. That's utterly too complicated.

Or maybe I am getting it all wrong?

I am proposing to use the same workflow that we used for versioning APIv1 a long time ago. I would like to add something like FEATURE_VERSION=123 into copr-rpmbuild and MIN_BUILDER_FEATURE_VERSION=123 variable to copr-backend. Then provide a copr-rpmbuild --feature-version command that would be called from backend instead of rpm -q copr-rpmbuild --qf \"%{VERSION}\n\".

Since those variables would be integers and in no way tied to a release process, the usage would be dead simple.

Also, please note that I am not suggesting to increment FEATURE_VERSION every time we make a change or add a feature. We don't care for that. I suggest incrementing it only when adding a new feature that backend depends on (e.g. PR#1780)