wiki.ipfire.org

The community-maintained documentation platform of IPFire

User Tools

Site Tools


devel:pakfire:guidelines:version_and_release

Package Version & Release Number

Version

The version information may only contain one of the following characters.

ABCDEFGHIJKLMNOPQRSTUVWXYZ
abcdefghijklmnopqrstuvwxyz
0123456789-_+

The underscore (_) is not allowed to be used as a delimiter. The use is exceptional for packages which have the underscore in the upstream name (like lm_sensors). If you want to use a delimiter to create a sub-package a dash (-) is to be used.

Choosing a good number

It is recommended to adapt the version of the original package or tarball. It is also a good idea to follow the names of other distributions to not confuse users that deal with other distributions as well.

For example:

3.0 or 2.6.27.15 like the Linux kernel
1.0.0c like openssl

It is not allowed to use version numbers like 1.0.0-RC1 because pakfire wouldn't be able to determine that 1.0.0 will be a newer version of that package. See below to learn how to deal with that.

Release numbers

A new package always starts with 1. After changes on the package the number has to be increased by one. If the package will be updated to a newer version, the release number has to be set back to 1.

In IPFire 2, the release number was always increased and never reset to 1. That has changed!

Don't make unnecessary gaps. If you commit a change only increment release by one except there are no other circumstances that require another change.

Development releases

Development releases are numbered in various ways. You should find an understandable way to tag them correctly and always be aware of monotony.

To make clear, this is a development release, all release tags start with 0.

General rules: Version must ever be the version number of the package. If you want to build openssl-1.0.0-RC1, then 1.0.0 is the version number.

Release candidates

Considering the openssl example from above, we can NOT easily set things like this:

name       = openssl
version    = 1.0.0-RC1
release    = 1

If the final package is release, the solver cannot decide which one is newer (1.0.0 or 1.0.0-RC1) and will install openssl-1.0.0-RC1. Increasing epoch is strongly discouraged in this situation.

A better solution would be this:

name        = openssl
version     = 1.0.0     # it is required to set version like this
release     = 0.1-RC1

release must start with 0 and we add .1 as a counter if we change anything on the package that requires a rebuild. Finally, -RC1 is appended to make it clear to the user which version he or she is currently running.

If the final package is released, we can set release to 1 and this is compliant to the normal process.

GIT versions

It should always be clear which version of a package a user is running. If it is a version which was taken from the upstream GIT repository and not yet tagged as a stable release, we must add this information to the package name.

We cannot add it to version because of monotony (see above), so we append it to the release number as shown in this example:

name       = libsolv
version    = 0.0.0
release    = 2.git0db9d7f

Don't forget to add the git keyword.

Package download path

In some cases using devel versions needs to fix the download url or the source grabber. In this case you can override them with the thisapp and the release tag.

name      = suricata
version   = 1.1
devel_ver = rc1
release   = 0.1-%{devel_ver}
thisapp   = %{name}-%{version}%{devel_ver}

This will download suricata-1.1rc1.

devel/pakfire/guidelines/version_and_release.txt · Last modified: 2019/02/21 22:00 by Jon