I've got a package where upstream that has basically stopped doing releases, so I package git snapshots. However, the last release they did was a pre-release (0.8.0rc1). Any suggestions on what an appropriate Release tag should be in this case? Something like: 0.%{releasenum}.rc1git%{shortcommit}%{?dist}

On Tue, 1 Sep 2015, Michael Schwendt wrote: >> I've got a package where upstream that has basically stopped doing >> releases, so I package git snapshots. However, the last release they >> did >> was a pre-release (0.8.0rc1). Any suggestions on what an appropriate >> Release tag should be in this case? >> >> Something like: >> >> %{shortcommit}%{?dist} > > Version: 0.8.0 > Release: 0.%{releasenum}.rc1%{?dist} > > That's the normal pre-release versioning scheme. > > Absolutely no need to insert the git snapshot stuff in there as well. > > In case you update to a future snapshot, it's possible to return to the > snapshot versioning scheme. Afterall, %{releasenum} is most significant > in both schemes, and if bumped correctly, anything right of it doesn't > matter during RPM version comparison. Sorry, I wasn't completely clear in what I'm doing. I'm updating to another git snapshot that is post 0.8.0rc1, so I *should* have the git hash in the version string, right? That's why I had come up with rc1git{hash}.

>>> I've got a package where upstream that has basically stopped doing >>> releases, so I package git snapshots. However, the last release they did >>> was a pre-release (0.8.0rc1). Any suggestions on what an appropriate >>> Release tag should be in this case? >>> >>> Something like: >>> >>> 0.%{releasenum}.rc1git%{shortcommit}%{?dist} >> >> Version: 0.8.0 >> Release: 0.%{releasenum}.rc1%{?dist} >> >> That's the normal pre-release versioning scheme. >> >> Absolutely no need to insert the git snapshot stuff in there as well. >> >> In case you update to a future snapshot, it's possible to return to the >> snapshot versioning scheme. Afterall, %{releasenum} is most significant >> in both schemes, and if bumped correctly, anything right of it doesn't >> matter during RPM version comparison. > > Sorry, I wasn't completely clear in what I'm doing. I'm updating to > another git snapshot that is post 0.8.0rc1, so I *should* have the git > hash in the version string, right? That's why I had come up with > rc1git{hash}. Then consider showing your current "Version" and "Release" tags to make the scenario clear. ;-) If you're already at "Version: 0.8.0" in the spec file, knowing since 0.8.0rc1 that the next version will be 0.8.0, and if you're packaging a snapshot newer than rc1, it's a pre-release snapshot. A snapshot made after rc1 isn't equal to rc1 anymore. Squeezing an "rc1" identifier into the package versioning scheme serves no purpose. It only makes the package EVR look more funny.