English Japanese
Versioning Guidelines
Fedora's package versioning scheme encompasses both the `+Version:+` and `+Release:+` tags, as well as `+Epoch:+`. The overriding goal is to provide sequences of packages which are treated as updates by RPM's version comparison algorithm while accommodating varied and often inconsistent upstream versioning schemes.
Some definitions
Note that upstreams may each have their own terminology and it is in general impossible to define these terms with complete generality. For some upstreams, every commit is itself considered a version. Some upstreams never make releases, instead just letting users take whatever is in the code repository at any given time.
release version
A version of the software which upstream has decided to release. The act of releasing the software can be as simple as adding a git tag. This includes so-called "point releases" or "patchlevels" which some upstreams make, since those are actually assigned versions and released.
An archive taken from upstream's source code control system which is not associated with any release version.
prerelease version
Before a release happens, many upstreams will decide which version that will release will have, and then produce "alphas", "betas", "release candidates", or the like which carry that new version but indicate that the release of that version has not yet been made. These we call prerelease versions. Any snapshots made while upstream is preparing for their release are also considered prerelease versions.
postrelease version
Any version which happens after a particular release is technically "post-release", but before upstream begins making prereleases for the next version, any snapshot is considered a postrelease version.
non-sorting version sequence
A sequence of version strings which is not ordered in the same way that RPM's version comparison function would order it. RPM has a somewhat complicated version comparison function which it will use to determine if a package is "newer". If upstream's idea of what constitutes a "newer" version differs from RPM's implementation then simply using upstream's versions directly will result in updates which don't actually update any packages.
Epoch: tag
The `+Epoch:+` tag provides the most significant input to RPM's version comparison function. If present, it **must** consist of a positive integer. It **should only** be introduced or incremented when necessary to avoid ordering issues. The `+Epoch:+` tag, once introduced to a package, **must never** be removed or decreased.
Simple versioning
Most upstream versioning schemes are "simple"; they generate versions like `+`. They consist of one or more version components, separated by periods. Each component is a whole number, potentially with leading zeroes. The components can also include one or more ASCII letters, upper or lower case. The value of a component must *never* be reduced (to a value which sorts lower) without a component somewhere to the left increasing. Note that the version sequence (`+1.4a+`, `+1.4b+`, `+1.4+`) does not meet this criterion, as `+4+` sorts lower than `+4b+`. The sequence (`+1.4+`, `+1.4a+`, `+1.4b+`) is, however, simple.
This is a very common versioning scheme, and the vast majority of software projects use something which works like this.
To package *release versions* of software using this versioning scheme: