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_packages
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
