"Michael J. Donahue" wrote:
> Does anyone know what standards might exist on generating Version and
> Release numbers for RPM spec files.
>
> ie. Version 1.2.3 Release 4
>
> 1 = major version - changes occurred that effect interfaces
> 2 = minor version - changes occurred but interfaces are the same
> 3 = possibly bug fix or configuration related updates.
> 4 = release candidate 4

"Standards"?! It's a good thing you put that in the plural.

I was under the impression that one "should" use the Version of the
Source Code (and/or tarball) for the %{VERSION} of the RPM, and then
bump the %{RELEASE} of the RPM for each tweak necessary for the
package. Thus, if the virgin-source tarball stays the same, then the
new patches added to the spec file would require a new %{RELEASE};
however, if the owner of the tarball put a new version number on the
patched code and published it as such, then the %{VERSION} of the RPM
would be bumped to match that tarball, and the %{RELEASE} would start
all over again (at 0 or 1, depending on whether you're deeply steeped in
C array index conventions or not).

One would also bump the %{RELEASE} for such details as "built for
RedHat" and "built for SuSE"; clearly, the original Source Code is
staying the same.

Looking at a typical distribution of 700+ packages, one quickly finds
that various programmers use different "standards", if any.
--
Mark Amidon | "Even within the walls of Microsoft,
amidon@... | Microsoft Outlook is known as
(978) 251-1987 x252 | 'Look Out!'."
http://www.whatiflinux.com | -- Erik Heino



_______________________________________________
Rpm-list mailing list
Rpm-list@...
https://listman.redhat.com/mailman/listinfo/rpm-list