The names of ProFTPD releases, which indicate the version of ProFTPD, can be a little confusing to users new to the software. This document is a brief guide to the naming conventions used for ProFTPD release versions.
Release Candidates
Every development/release cycle of the ProFTPD software begins with series of
release candidates (RCs), e.g. proftpd-1.3.2rc1.
The "rc1" suffix in this example indicates that this is the first release
candidate of the 1.3.2 development/release cycle. A suffix of "rc2" would
be used for the second release candidate, and so on. The first release
candidate (RC1) is where most of the new features of that development/release
cycle tend to be added, including new core APIs, new modules, deprecated
configuration directives are removed, etc. Subsequent release
candidates tend to focus on stabilizing the new code and fixing bugs. There
can be few or many release candidates, depending on the number of new features
added and bugs encountered.
Stable Release and Maintenance Branch
Once the code base is considered stable, and the frequency of new bug reports
has slowed down, then the "stable" release is cut. A "stable" release has
no suffix in the name, e.g. proftpd-1.3.2. At the
same time, the code is branched, creating a maintenance branch for that
development/release cycle. The trunk continues on to become the basis for the
next development/release cycle. At any given time, the ProFTPD Project team
supports the most recent maintenance branch, and the current trunk. When a new
maintenance branch is created, the previous maintenance branch is no longer
supported. Thus when the 1.3.2 maintenance branch was created, the 1.3.1
series of releases became unsupported.
Maintenance Releases
During any given development/release cycle, bugs will be reported against
older versions of ProFTPD. The fixes for those bugs will be developed
using the current version of ProFTPD. If the bug is deemed to be serious
enough, then the fix will be backported to the active maintenance
branch as well. Serious bugs include security vulnerabilities, major bugs
not found during the previous development/release cycle, and new translations.
Thus there will continue to be releases for a given cycle after the "stable"
release; these maintenance releases come from the maintenance branch.
Maintenance release names use letters, rather than numbers, in the suffix
portion of the release name/version. The first maintenance release will be
"a" (e.g. proftpd-1.3.2a), the second will be "b", and so
on.
Using the 1.3.2 development/release cycle as an example, then, the releases for the cycle are:
Checking the Version
If you are not sure of the version of ProFTPD you are running, the best way
to check is to use the -V command-line option for proftpd.
The -V option shows the various build-time options used for your
proftpd; the version information is at the very beginning of that
output:
$ proftpd -V
Compile-time Settings:
Version: 1.3.2rc1 (devel)
The above shows that the proftpd version on the machine is
the first release candidate of the 1.3.2 development/release cycle. The
portion of the version in parentheses, i.e. "(devel)" in the example
above, is a version label. Version labels are intended to make it
very clear which type of release that proftpd executable comes
from, rather than having to figure it out based on the suffix of the version
name. Release candidates always use a "devel" version label.
If you are running a stable release, then you would see:
$ proftpd -V
Compile-time Settings:
Version: 1.3.2 (stable)
The version label for stable releases is always "stable", obviously.
For completeness, here is what the -V output for a maintenance release
looks like:
$ proftpd -V
Compile-time Settings:
Version: 1.3.2a (maint)
The version label for a maintenance is "maint".
Finally, for developers and users who use the latest and greatest code from the master branch on GitHub, you will see something like:
$ proftpd -V
Compile-time Settings:
Version: 1.3.6rc1 (git)
All code obtained from GitHub reports a version label of "git".