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}
Scott
On Mon, 31 Aug 2015 23:34:15 -0400 (EDT), Scott Talbert 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.
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}.
Scott
On 09/01/2015 03:23 PM, Scott Talbert wrote:
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}.
The essential point in EVRs is steadiness (They must steadily increase). I.e. simply changing git hashes in %release won't work because they are not guaranteed to be steadily increasing.
I.e. you need to change your %release-string's naming scheme.
Ralf
On Tue, 1 Sep 2015 09:23:12 -0400 (EDT), Scott Talbert wrote:
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.
If you check out code that is exactly rc1, well, you can name it such, but all that matters is that the pair of %version and %release is increasing in a way it upgrades the previous package release.
It's
Release: 0.%{X}.%{alphatag}%{?dist}
for all pre-releases, snapshots included. The %{X} is the most important number. Everything right of it is just for all those, who take a closer look. The checkout date also only serves an informational purpose (e.g. a user may recognize the age of a snapshot without having to look under the hood).
So, for a pre-release git snapshot it's
Version: 0.8.0 Release: 0.%{releasenum}.%{YYYYMMDD}git%{shortcommit}%{?dist}
or
Version: 0.8.0 Release: 0.%{releasenum}.%{YYYYMMDD}git%{?dist}
or even
Version: 0.8.0 Release: 0.%{releasenum}.%{YYYYMMDD}snap%{?dist}
because whether the SCM is git or something else is irrelevant, too.
That's the normal pre-release snapshot versioning scheme.
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Snapshot_packages https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packag...
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
packaging@lists.fedoraproject.org