ProFTPD: Release Versioning


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".

Frequently Asked Questions

Question: When you say that older maintenance branches are no longer supported, what exactly does that mean?
Answer: Support, in this case, refers to whether the ProFTPD Project team will provide patches for a bug that can be applied cleanly that version of the source code. Bugs can (and indeed should) be reported against that version, but the fixes will be applied in the newer, supported versions of ProFTPD instead of in the unsupported branches.