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:
>>>
>>> 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.
Got it. So, bottom line: it isn't *exactly* rc1, so the pre-release git
snapshot rule should be followed.
Thanks for the detailed response.
Scott