The ClearOS release cycle is dependent upon specific development processes. There are several discrete products as well. This article covers the release process for:

• ClearOS Updates Release Cycle
• ClearOS ISO Release Cycle
• ClearOS Preload Release Cycle (including OEM preloads)
• ClearOS Major Version Release Cycle

The ClearOS update cycle follows this basic process:

• Source code or blob entered into git repository (can be from upstream rebuild process)
• Intake and build by koji build system.
• Push to testing repositories on mirrors (public and private)
• Review by developer and community
• Push of package to community updates repository by Package Release Manager.
• Review by community and end users.
• Push to verified updates repository by Package Release Manager (not contrib packages)

Except for the major release Cycle. Rebuilds of the ISO occur once all the packages are updated to verified for all of the core products in a minor release. This build and rebuild will typically happen quarterly and roll up any packages that are produced in the interim. This means that there can be several minor version ISOs

• Validate all packages are sane
• Validate that install packages are working in test
• Build ISO image
• Release to testing folder on public repos
• Validate working copy or restart process for bad test ISO
• Move ISO from test to production
• Move symlink for version to new version

• Validate ISO function
• Inject ISO in builders
• Build Preload image
• Test internally
• Test with vendor performing preload

This process is about producing ISOs worthy for general release. The target is a Release Candidate that doesn't have have significant bugs that require withholding the release. In general, developers will start with an upstream version (even a previous upstream version) and amend it to ClearOS. Once a significant amount of collateral is available to produce the initial ISO. That ISO starts the process:

• Package set pushed to verified repos for initial release.
• Initial alpha build from verified repo.
• QA until ready for Beta
• Beta released from verified repo
• Interim alpha's built from updates repo until end of beta
• Successive beta from verified until ready for Release Candidate
• Release Candidate from verified repo
• Interim alpha's built from updates repo until end of Release Candidate
• Replacement Release Candidates put forward until there is satisfaction with the quality
• Recut Release candidate without 'testing' nag as the initial release.