+1 (as proposer)

TL;DR seems to be "append +build%{buildnumber} to the %dist tag if the %buildnumber macro is defined"?

That should be fine, so +1 ...

RPM also appears to sort +build10 correctly after +build2 even without a separator character, though I would prefer having a separator character betwen +build and the actual number for better readability.

+ is considered equivalent to . for sorting purposes, but is visually distinct and +build<number> is similar to how Debian/Ubuntu does this, so I figured it'd be good enough.

I'm also generally in favor of doing this (or something close to it). +1 from me for the general idea, though the exact naming is slightly in question. In the fedora-release merge request, @gotmax23 raises the question of whether we should follow the example COPR set with %buildtag. I don't think reusing %buildtag is the right call, but I wanted to make sure we properly consider it before making a decision.

Edit: clarified which suggestion I disagree with.

Yeah, I deliberately did it differently because %buildtag is defined with different semantics. And I want to define %buildrelease with human-comprehensible semantics and numerology (more similar to OBS' build counter, where it's easy to tell how many builds have been done of a particular name-version-baserelease set).

+ is considered equivalent to . for sorting purposes, but is visually distinct and +build<number> is similar to how Debian/Ubuntu does this, so I figured it'd be good enough.

I wrote:

I would prefer having a separator character betwen +build and the actual number for better readability.

so +build.1 instead of +build1 - but it appears that both get sorted correctly by RPM.

so +build.1 instead of +build1 - but it appears that both get sorted correctly by RPM.

I disagree, as we already have .fcNN and .elnNNN as historical precedent. We should remain consistent.

That was why I did it this way actually. :sweat_smile:

I don't mind the approach and it's a pretty minor change, but I just don't understand why we should push this change to all our users before there's something that we might approve using it.

Can you not simply have your own fedora-release package with the macro for setting up your POC?
Then, once it's all working as you like, you can propose the entire workflow which would include adding/modifying the macro for it's needs?

I mean, perhaps this doesn't work out as you want and we have to adjust it more?

Anyhow, if it's just me and everyone else is ok making changes like this fine...

I like the idea and would be +1, but as Kevin, I would prefer to have the rebuild part ready, so that when the repos are impacted, it is already possible to show how it works.

Well, it may take upward to a year to have it in the main build system, but it may be possible to talk to the Copr folks about plugging support in.

I'm working on a simple demonstration implementation that just uses mock to show exactly what the semantics are expected to be.

I don't mind the approach and it's a pretty minor change, but I just don't understand why we should push this change to all our users before there's something that we might approve using it.

Can you not simply have your own fedora-release package with the macro for setting up your POC?

The problem is that getting work done for it has been a series of catch-22 issues for years. This unlocks at least one aspect in that for existing build systems that already have the capability, we can plug this in today and give other build systems time to incorporate the feature and leverage it.

~~Off the cuff, I'm pretty sure we can use this with the Open Build Service pretty much right away. And if not, it should be easy to extend its build counter support to populate a macro too.~~

EDIT: It seems it's a little tricky to get the values as a macro right now in the Open Build Service, but I've opened a feature request with them for it: https://github.com/openSUSE/open-build-service/issues/18841

I'm working on a simple demonstration implementation that just uses mock to show exactly what the semantics are expected to be.

I would already be happy with this :)

I think the general request is OK. +1, with the clarification that there'll be discussion in the PR about the details of implementation before it is merged.

+1 for the general idea, and we can hash out the details in any submitted PR

OK, the tally is (+4, 0, 0), which doesn't count the people saying that they'd be +1 but prefer to have an implementation first. Nobody voted 0 or -1. So I'll count this is approved. Let's continue the bikeshedding^Wdiscussion about naming in the implementing pull request.

ACCEPTED: (+4, 0, 0)

Announced: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QB7SUIXOWCFUO24SU2GPLBRXBYHY7OBW/