The FabGuard Product Team is introducing a new software development and deployment process. The new process is designed to ensure long term stability of releases while maintaining the short cycle times needed for rapid prototype and development. This new strategy employs a two track development process. The production release track will happen on a six month cycle while the development release track will maintain regular releases. To better facilitate the new process, future FabGuard versions will be numbered differently than in the past. The new versioning structure contains the version number, the revision number, and patch level of the release in the form YY.MM.RV-PATCH, Figure 1.
The major version number is listed as the year and month of the release, “YY.MM”. The revision number indicates feature changes from the base deployment, “RV”. The patch letter is used to identify the level of defect fixes to the version.revision and is indicated by “P”.
The primary production release for April 2017 with patches would be listed as 17.04.00-b. The “.00” revision indicates that this is the production release and the “-b” indicates the software is at patch level b (-a is the 1st patch, -b is the 2nd patch, etc), Figure 2.
INFICON will continue to perform continuous improvement and development to the FabGuard product line. New features will be put into new revisions (.01, .02, .03 etc.) and will be branched from the production release (.00). This means that all development releases are enhancements to the primary revision and contain new features and capabilities. To continue with the above example, the 1st development release of the 17.04 version would be 17.04.01 and the 2nd development release would be 17.04.02. Each of the development releases could be patched to correct software defects. This means that the 4th patch of the 3rd revision of 17.04 would be 17.04.03-d.
Due to the new versioning methodology, INFICON will be maintaining two tracks of the same major version (17.04): 1) a production revision (.00), and 2) a single developmental revision (.01, .02, etc.). At the end of a 6 month cycle, the current production version will be moved into end of life and a new production version will be released. For example, 17.04 will be transitioned to end of life and 17.10 will be released. Once a version is moved into end of life no new revisions or patches will be developed for that version. Any new features or patches will be supported in the new production version, Figure 3.
The new software development and deployment process provides a stable factory release and a development release for integrating rapid prototype and development work. This process will satisfy the needs of both factory level and sensor development level engineers. Additionally, the new version number structure provides the software release date and its intended use in the field directly.