TurboVNC | DeveloperInfo / Versioning, Code Quality, Branching, and Long-Term Support

Versioning Scheme

TurboVNC uses a variant of the "Numeric 90+" versioning scheme. Pre-release builds, beta releases, and release candidates use the same major/minor version number as the most recent stable release series, but a high revision number is used to indicate that the build is from a new release series-- x.x.80-x.x.89 for alpha/evolving builds (may not be feature-complete), x.x.90-x.x.94 for beta releases and post-beta builds (feature-complete but not heavily tested in production environments yet), and x.x.95-x.x.99 for release candidate builds. We use this scheme because:

It does not force us to choose a major/minor version number for a new release series until it enters the beta testing phase.
It ensures that packaging systems will always treat a next-gen pre-release as newer than the current stable release but older than the next-gen stable release, once it becomes available.

Code Quality

Each TurboVNC release series falls into one of the following code quality categories (listed in ascending order of quality and code age):

Alpha/Evolving: Has usually undergone bench testing to ensure that, to the best of our knowledge, all features work properly. However, alpha/evolving code bases and builds are not feature-complete, so interfaces may not be finalized, and the code may not have been tested thoroughly by the community. Alpha/Evolving code bases and builds are no longer supported by The VirtualGL Project after the release series enters the beta testing phase.

Beta: Feature-complete and has undergone more rigorous testing by us but may not yet have been tested thoroughly by the community, particularly in production environments.

Post-Beta: Includes fixes for bugs discovered after the beta release.

Release Candidate: Generally a release candidate is issued only if one or more of the post-beta bug fixes required significant and potentially disruptive changes to the code base. If no further bugs are discovered in the release candidate, then it becomes the first stable release in the series (the .0 release.)

Beta, Post-Beta, and Release Candidate code bases and builds are no longer supported by The VirtualGL Project after the release series leaves the beta testing phase.

Stable: After a new release series has undergone a beta testing phase (which usually lasts about three months), it is considered stable and complete. Any subsequent releases from that series will contain only bug fixes or minor, non-disruptive enhancements meant to address usability or compatibility problems, improve test coverage, or address any other oversights.

Branching and Long-Term Support

Each TurboVNC release series has a dedicated Git branch that falls into one of the following support categories (listed in ascending order of code age):

Next-Gen: The code contained in the branch is of Alpha/Evolving quality. Pre-release builds are continuously generated whenever a new commit is pushed. The dev branch is the only Next-Gen branch, and it is the only branch into which major new features will be introduced. When a new release series is feature-complete and ready for beta testing, it will be merged from dev to main, and a new branch will be created for the previous release series that was formerly in main. If no major new features have yet been introduced relative to the current release series, then the dev branch will not exist.

Active: The code contained in the branch is of Beta or higher quality. Pre-release builds are continuously generated whenever a new commit is pushed, and official bug-fix releases are issued from the branch approximately every three months if there are enough bug fixes to justify them. The main branch is always Active. The branch for the previous release series is also Active while the current release series is in the beta testing phase.

Maintenance: The code contained in the branch is of Stable quality. Any relevant fixes or non-disruptive enhancements from the current release series are proactively back-ported into the branch, and pre-release builds are generated from the branch whenever a new commit is pushed. Official bug-fix releases are rarely or never issued from the branch, but project sponsors can request an official Extended Support Release from the branch if there are enough bug fixes to justify it. The branch for the previous release series transitions from Active to Maintenance when the beta testing phase for the current release series is complete.

Extended: Only critical fixes from the current release series are proactively back-ported into the branch, and pre-release builds are not generated from the branch. Extended Support Releases are not issued from the branch, but project sponsors can request an official signed build from the branch.

EOL: The code contained in the branch is no longer supported, developed, or tested in any way by The VirtualGL Project unless an organization specifically pays for that support.

Current branches:

1.0.x - 1.0.x Stable (EOL)
1.1.x - 1.1.x Stable (EOL)
1.2.x - 1.2.x Stable (EOL)
2.0.x - 2.0.x Stable (EOL)
2.1.x - 2.1.x Stable (EOL)
2.2.x - 2.2.x Stable (Extended)
3.0.x - 3.0.x Stable (Maintenance)
main - 3.1.x Stable (Active)
dev - 3.2 Evolving (Next-Gen)