Yay for consistent pre- and post-release snapshot versioning, I guess? :tada:

Side note: have the rpm 4.15 segfaults been fixed?

Yes and yes :)

I think it might be just slightly premature to do this, but I obviously will need to dig out my old drafts and present them at some point and there's no reason not to do this soonish. I expect there will still be a few issues to hash out.

@tibbs this is hard blocker for an automation I'm working on to automatically rebuild packages on a dependency change. So I would like to deal with this one as soon as possible.

Initial PR submitted as #908.

One important thing to note: If you put a caret into the Version: tag of a specfile, RPM on anything except for rawhide will simply refuse to parse it:

ἐπιθυμία:~/work/local-packages/coin/❯ rpmspec -P *spec
error: line 15: Illegal char '^' (0x5e) in: Version: 4~^20190624.bd4a9ad02af2

So if we do go ahead and do this, we'll have a whole class of spec files that rpm on any supported release won't even parse. So I'll revise my earlier statement to simply: I believe that it's premature to do this. It might not be a terrible thing if a couple of packagers wanted to experiment with it, but to say that everyone should be using it or that we should build automation around it is simply too much. After F31 is out, sure.

I know it would be possible to simply backport the simple patch which adds this, but I understand that there's opposition to that. (Which I don't really understand as there's a history of things, including tilde, being backported.) Personally I'll just end running a backport locally self so I don't have to move to rawhide everywhere I want to experiment with this. If we did get a backport then I'd be all for it.

@tibbs it is chicken-egg problem. Tilde was backported because there were complaints that "we can't use tilde because it is not in EL6". And even after that we did not use tilde until recently. So RPM folks are allergic to backport anything what is not even used in Rawhide.

We already have features which make new specs non-parseable on old RPMs. For example, %patchlist/%sourcelist/%generate_buildrequires.

We talked about this issue this week:

https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2019-07-11/fpc.2019-07-11-16.00.txt

• #904 Caret versioning (geppetto, 16:44:22)
• ACTION: tibbs will add list of things that need testing. (geppetto,
  17:00:45)
• In general we seem fine on adding this after F31 GA, and probably
  even F31 branch. (geppetto, 17:01:10)

FWIW, you can expect (at least) one more upstream release on the 4.14.x branch that will be rolled out on all current Fedora versions, and that update is expected to have caret support included. Can't yet say when exactly this will happen but "after 4.15 final is out and before the end of the year" would be the rough ballpark.

This is good news; thanks for letting us know.

@pmatilai what's the status here?

The ballpark estimate still stands, but @ffesti will be doing the 4.14.3 release so you need to ask him for details.

@ffesti any change we can have caret versioning in F30?

The RPM 4.14.3 rebase landed with RHEL 8.3, so we should be all clear to finally start adopting it.

Implemented in #1073.