Versioning

Firebird version consists of four numbers, namely: major version, minor version and release version, followed by the build number. Firebird major and minor version numbers together uniquely identify the Firebird version series, i.e. binaries with their own set of features. Each of those version series is developed and maintained separately. Usually, the project increments the major version number only after noticeable amount of architectural changes or after a major ODS (database on-disk-structure) change which is incompatible with prior ones. The minor version number is incremented per every new feature set added into the same major version and the resulting binaries combine a new Firebird version series.

The release number (aka point release or maintenance release number) generally represents a service pack, and is incremented per every set of bug fixes added into the particular version series. Point releases never contain new features, although they may include some minor improvements (usually in the performance and security areas). We highly recommend to upgrade to the latest point release of your version series as soon as it arrives!

Migration from one version series to another (e.g. 1.5 -> 2.0 or 2.1 -> 2.5) requires to recreate the database on a newer version (usually via the backup/restore cycle) in order to use all the new features. Migration to a newer point release (e.g. 2.1.3 -> v2.1.4) doesn't require recreating the database, although in some cases it could be advised to do so (e.g. when some bugfix covers the ODS related database internals).

The build number is incremented automagically per the every change committed into the source code repository, and thus it's useful to distinguish between different incarnations of the same Firebird version, usually between the official release and some snapshot build.

Firebird version string consists of the aforementioned version number surrounded by some additional information. The prefix consists of two parts: unique platform identifier (Windows/Linux/etc) and the build type (stable/unstable). The suffix adds the textual representation of the release series and possibly some extra information (custom build tag, unstable mark, etc).

Examples:

• WI-V2.1.4.18393 Firebird 2.1
Windows, official final (V) release series 2.1, point release 4 (fourth service pack), build 18393
 
• WI-T3.0.0.29316 Firebird 3.0 Unstable
Windows, in-development (T) release series 3.0, point release 0, build 29316

Development Cycle

The project tries to balance between the feature based and time based release schedules. Each version to be developed has its primary and secondary goals assigned. It cannot be released without the primary goals achieved, but some of the secondary goals could be "cut off", i.e. postponed to the next version series if the development process exceeds the reasonable time frame. The average period of the development cycle is two years.

New version series start with collecting the requirements and agreeing on the desired features for this particular release. The version series enters the initial development stage and stays there until the primary features are draftly completed. During this time frame, unstable snapshot builds are being published and the early field testing is possible, tracking the found issues against the initial version.

After that, the Alpha version is published, meaning that the project wants to involve wider audience to the field testing. Also, it usually means that the ODS is more or less stabilized and the subsequent builds can access the same database without unexpected issues. During the Alpha stage, the primary features are being finalized and secondary features are being developed or improved. There may be two or more Alpha versions released.

As soon as all the primary features are implemented, the development switches to the Beta stage. This is coupled with a "feature freeze" mode, meaning that no new features are allowed and the team is focused on the bug fixing. There may be two or more Beta versions released, depending on the field testing results.

Once all the known issues are fixed, the Release Candidate (RC) stage is entered. The version string gets prefixed with "V" instead of "T", thus meaning being stable and nearly ready for production use. If there are no regressions reported during the fixed period of time (usually one month), the RC version gets renamed and becomes the final release. Otherwise, the known bugs get fixed and the new RC build gets published. This cycle is repeated until no new regressions are found.

Maintenance Policy

While being primarily focused on the new development, the project also does its best in maintaining the already released version series. New point releases are produced regularly and incorporate fixes for all the known regressions and security issues. Every released package is tested by the project QA team to ensure that the priorly fixed issues would never strike back.

The latest releases are maintained twice a year. Version series initially released more than 5 years ago get discontinued and are not maintained anymore. More maintenance details can be found in the roadmap.

Besides the official releases, snapshot builds for Windows and Linux platforms are published daily. They can be used to benefit from some fixed bug immediately, without waiting for the next point release. However, beware that point releases are not tested properly, so they would be used on your own risk.