When upstream has never chosen a version, you MUST use Version: 0. “0” sorts lower than any other possible value that upstream might choose. And if upstream does choose to release "version 0" then you can immediately move to using Release: 1%{?dist} with no ordering issues.

It’s possible that upstream uses characters besides ASCII letters (upper and lower case), digits and periods in its version. They must be removed and potentially replaced with valid characters. Any such alterations MUST be documented in the specfile. It is not possible to cover all potential situations here, so it is left to the packager to alter the upstream versioning scheme consistently.

After altering the version to be free of invalid characters, see #Unsortable versions below if the modifications, when applied to successive releases from upstream, will not order properly.

When upstream uses a versioning scheme that does not sort properly, first see if there is any portion which can be removed from the right side of the version string such that the remainder is sortable. This is often possible if upstream uses a sequence like ("1.2pre1", "1.2pre1", "1.2final"). If so, use the removed portion as above, and the remainder as the package version. If this splitting leaves a leading or trailing period in either value, remove it.

If this is not possible, use Version: 0 and move the entire version string into .

All snapshots MUST contain a snapshot information field () in the Release: tag. That field must at minimum consist of the date in eight-digit "YYYYMMDD" format. The packager MAY include up to 17 characters of additional information after the date. The following formats are suggested:

Where is a short string identifying the source code control system upstream uses (e.g. "git", "svn", "hg") or the string "snap". is either a short git commit hash, a subversion revision number, or something else useful in identifying the precise revision in upstream’s source code control system. Obviously if CVS is used, no such revision information exists, so it would be omitted, but otherwise it SHOULD be included.

In the Version: tag, use the version that upstream has determined the next release will be. For the field of the Release: tag, use a number of the form "0.N" where N is an integer beginning with 1 and increasing for each revision of the package. Prerelease versions MUST use a Release: tag strictly less than 1, as this is the sole indicator that a prerelease has been packaged.

For the field of the Release: tag, use an integer beginning with 1 and increasing for each revision of the package. Release and post-release versions MUST use a Release: tag greater than or equal to 1.

It is possible that upstream simply adopts a different versioning scheme, fails to follow an expected pattern, or even simply resets their version to some lower value. If none of the above operations can help with giving a version which sorts properly, or give you a version which simply sorts lower than the packages already in Fedora, then you have little recourse but to increment the Epoch: tag, or to begin using it by adding Epoch: 1. At the same time, try to work with upstream to hopefully minimize the need to involve Epoch: in the future.

Sometimes, you may find yourself in a situation where an older branch needs a fix, but the newer branches are fine. For example, if pkg = 1.0-1%\{?dist} in F and F, and only F needs a fix. Normally, you would need to bump the release in each of the branches to ensure that F < F, but that is a waste of time and energy for the newer branches which do not need to be touched.

In this case, you MAY set to an in integer beginning with '1' and increasing by one for each minor bump you need to do. Remove once you are able to increase the package release normally without introducing ordering issues.