Releases

Edge Releases

You can find all the releases here.

Edge Release Format

Edge releases will be of the format:

edge.<YY>-<MM>-<DD>

These releases do not contain any SLA or semantic versioning guarantees, but we will announce breaking changes in the changelog.

This project maintains a strictly linear history. Bug fixes and new features will be added in new releases only (i.e., they will never be back-ported).

Edge Release Cadence

We have no set cadence for the community stack, but generally we will release changes 2-5 times per month.

Edge Release Support

We only offer extended support and enhanced resolution SLAs for our stable releases (see below).

Stable Releases

Stable releases are available only to stack subscribers.

You can find all the supported releases here.

Stable Release Format

Each release will be of the format:

<YY>-<MM>.<patch_number>

For example, 24-01.5 represents the fifth patch to the major version released in January 2024.

While this deviates from the normal practice of many open source projects which tend to use semantic versioning, we do this for good reasons:

• The stack is not a standalone utility, but rather a packaging of 100s of utilities that all work together. Regardless of whether new functionality is added, we MUST update our component systems regularly to keep up with the ecosystems that we target (e.g., Kubernetes). In many ways, it resembles a package registry like nixpkgs. We take inspiration from these registries which have time-based vs. functionality-based release names.

• With time-based releases, every release should be considered a major release with functionality changes that consumers should review for potential breaking changes. This could be conveyed using an integer for a major version number (e.g., 1, 2, 3, etc.). However, we can do better: the version timecode <YY>-<MM>. This retains the sortable property of integers, but adds additional contextual information that reflects our time-based release practices.

• The version timecode allows users to immediately know whether that version is still officially supported by Panfactum maintainers. See the support policy below.

• We additionally provide a patch number for when we backport bug fixes to previous releases. While we could simply update each <YY>-<MM> release directly, a patch number provides the following benefits:

  • Many utilities use caches and/or lockfiles. Even if we update branch <YY>-<MM>, there is no guarantee that you would receive the new updates (e.g., flake.lock would prevent this with nix flakes). Providing a patch ensures that those caches and/or lockfiles would receive the new code.

  • There are several automations such as renovate or dependabot that will notify you if code changes, but only if you cut a new discrete release number. For critical items like security patches, we want our users to be able to receive notifications if they should update immediately.

Stable Release Cadence

We aim to create a new major stable release of the Panfactum stack twice per year.

We strongly recommend that users of the Panfactum stack update at least once a year.

We strongly recommend that patch versions of the Panfactum stack are applied immediately. We only create new patches if there are significant fixes for bugs or security vulnerabilities.

We endeavor to never introduce breaking changes in patches. If a fix requires breaking functionality, we will cut a new major release.

Stable Release Support

Major releases will receive patches for significant bugs or security vulnerabilities for twelve (12) months following its initial release.

For example, version 24-01.X will receive support until the end of January 2025.

"Significant" will be determined by a combination of the following criteria:

• Does it impact the recommended way to utilize the stack?

• Does it create a clear impairment of intended functionality or a clear security vulnerability for users of the stack?

If the answer to both of these questions is "yes," then it is likely:

• We will attempt to resolve the issue within 30 days

• We will patch supported releases