INFICON Release Notes Standards
INFICON Release Notes Standards
Breadcrumbs

Release Notes Standards

This page contains the standardization of INFICON release notes. Use these guidelines when applying styles and standards to release notes.

Version nomenclature:

  • Our version nomenclature is compliant with Semantic Versioning (SemVer) as documented at https://semver.org.

  • Each version has three tokens:

    • The first token is a four digit number representing the year and month like 2309 or 2405.

    • The second token is a single digit which is normally 0 or otherwise represents a "critical business need out of cycle" release as documented below.

    • The third token is the hotfix identifier which is 0 for the initial release following by 1, 2, …, 9, 10, 11, etc.

  • Our versions are sortable until we get to the 10th bug fix but SemVer does not allow padding with extra zeroes.  Therefore, it is not possible to be fully sortable.  For example, 2405.0.09 is not allowed by SemVer and instead must be 2405.0.9.  This will sort after the next bug fix 2405.0.10 but we must accept this.

  • Our alpha, beta, and rc (release candidate) versions also follow SemVer standards where the three token version is followed by a hyphen then alpha/beta/rc. Following alpha/beta/rc will be either:

    • A period then 1, 2, …, 9, 10, 11, etc.  For example, 2405.0.0-alpha.12 or 2405.0.0-beta.3 or 2405.0.0-rc.1. DWH always uses this convention since it cannot do automatic builds.

    • A plus sign then the build number. For example, 2405.0.0-alpha+2291 or 2405.0.0-beta+4732 or 2405.0.0-rc+6789. Most other applications use this convention for automatic builds. The build numbers are numerically sortable but not alphabetically sortable because of the lack of zero padding. This means that alpha+1234 is guaranteed to be a newer build than alpha+789 and that the newest alpha or newest beta or newest rc is the one with the highest build number.

For quarterly releases:

  • Suffix alpha means that we built a version to deploy and test a particular feature but we're continuing to add other features in the version.  Technically every commit could be an alpha, but if we do some amount of preparation for a particular alpha then we should number these alpha.1, alpha.2, alpha.3, etc.

  • Suffix beta means that all development is done for the version.  The first beta versions for all applications who wish to participate in the quarterly release will be released in synch.  These will be labeled beta.1.

  • If a product owner chooses to skip this particular quarterly release for their application then the newest officially released version will be used for regression testing on this release on the new beta DWH.  It is critical that the DWH Release Notes page for each quarterly release lists the newest officially release version of every application so it is clear which version of each application should be installed for a new site deployment using the DWH version (or for an existing site upgrading to the DWH version and wanting to upgrade all apps).

  • The first step of the beta.1 is to deploy to the newly created FPS_QA_xx database for regression testing as detailed at https://inficonims.atlassian.net/wiki/spaces/ISAP/pages/354287623. The second step is to deploy to FPS_QA_LIVE for further regression testing with live data.  There will likely be at least two beta versions of most applications (the first one for FPS_QA and the second one with fixes from FPS_QA to deploy to QA_LIVE) but we could do further rounds (i.e. we found issues at QA_LIVE with beta.2 so we build beta.3).

  • While beta.1 will be released in synch for all applications, subsequent beta.2, beta.3 will be independent and only released for each application as needed.  Therefore not every application will have a beta.2, beta.3.

  • Suffix rc is a release candidate meaning that we passed testing on QA_LIVE and this is ready for deploy to all client site test databases.  Again there should be rc.1, rc.2, rc.3 where rc.2 is really a bug fix on rc.1 found during testing at a client site test database.

  • The rc.1 versions for all applications who wish to participate in the quarterly release will be released in synch but rc.2, rc.3 will be independent similar to beta.2, beta.3 above.

  • The officially released version for each application is at the discretion of each product owner.  Release candidates may be run in production (the "sendahead" philosophy) and, in most cases, the product owner will decide to officially release either when the first client site wishes to go to production or after a few days of having at least one client site running in production.  However, the product owner might decide to let a release candidate run in production for a longer period before releasing.  Or if no client site wants to go to production for a particular application but the product owner believes that the application is working on enough client site test databases then the product owner can decide to release.

  • By definition, the officially released versions will likely not be in synch.  This is because the decision to officially release each application is at the discretion of each product owner.

  • The DWH will be released along with the first application if not before.

 For "critical business need" out of cycle releases (a.k.a. "second token" release):

  • These critical business need releases will be used sparingly.  In most cases, we hope to provide an alpha release to the client for testing in advance of the quarterly release rather than an official "critical business need" release. 

  • Each critical business need must be jointly approved by Marketing, Operations, Development, and the product owner of the application.

  • Any of the four groups could initiate a critical business need request.

  • In most cases, we will push features not ready for the quarterly release to the next quarterly release.  In some cases, we might delay the quarterly release until a critical feature is ready.  But we have this third option when neither pushing nor delaying is feasible.

  • Typically these releases will not have full regression testing.  Instead, an alpha version will be deployed to the site with the critical business need and then we will officially release out of cycle using the second token once testing at that site has passed.

  • These releases will typically only be deployed to the site(s) that have the critical business need.  We may not even announce these releases to the general population. 

  • The first token of the version will be the DWH required for the critical business need release which will usually be the newest DWH version but not always, especially if the critical business need application does not require DWH changes.

  • We expect that after the next quarterly release that including these features is officially released that we can end support for hotfixes to the out of cycle release.  Certainly once the one site with this out of cycle release has upgraded to a newer version then we can definitely end support.

  • These critical business need releases will typically be incorporated into the next quarterly release. Support via hotfixes for these out of cycle releases will end after they are incorporated into a quarterly release which has been upgraded at the requesting site(s).

  • NOTE: The second token in the DWH version could be for a critical business need release to support an application of the same release, but it could also have a different meaning which is a breaking change.  For example, Scheduler 2309 was a breaking change but other 2309 applications were not.  To support this, we provided DWH 2309.0.0 which supported all 2309 applications other than Scheduler and worked with older versions of Scheduler along with DWH 2309.1.0 which supported all 2309 applications including Scheduler 2309 but did not work with older versions of Scheduler.  To find out whether DWH versions with a second token other than zero are critical business need or breaking change, please see the DWH Release Notes.

For hotfix versions:

  • The alpha -> beta -> rc official syntax from above still applies.  The alpha could be tested anywhere, for example a build with one bug could be an alpha for the hotfix.  We always deploy the beta version to the appropriate FPS_QA_xx database for that minor version first.  Once it passes on FPS_QA_xx then we will likely go directly to rc.1 to test on a client site.

  • For a larger bug fix, we might choose to merge forward and test the newest version on FPS_QA_LIVE before releasing a whole round of rc.1 versions for all hotfixes but this is optional.  Again once any client site is ready to go to production then we officially release the version as .1 or .2 or .3 or whatever.

  • When a particular hotfix is officially released, any other hotfixes nested in that hotfix are also released.  For example, we might release 2311.0.3-rc1 with all fixes included into 2402.0.2-rc1 with all fixes included in 2405.0.1-rc1.  Then when one site goes to production with 2402.0.2 that will also release 2311.0.3.  But it will not release 2405.0.1.

  • Obviously all applications will release hotfix versions independently with the exception that a particular hotfix might require a corresponding DWH hotfix.  There is also the extremely rare case where an integrated feature that crosses applications needs a multi-application synchronized hotfix.