feat: add release docs

packages/website/src/app/(web)/docs/guides/versioning/releases/page.mdx

@@ -1 +1,68 @@
-# Releases
+# Releases
+
+## 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](https://semver.org/),
+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](https://github.com/NixOS/nixpkgs). We take inspiration from these
+registries which have time-based vs. functionality-based releases.
+
+- With time-based releases, _every_ release should be considered a major release with functionality changes that consumers
+should review. 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.
+
+- This helps users know at a glance how current their instance of the stack is, and whether it 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](https://docs.renovatebot.com/) or [dependabot](https://docs.github.com/en/code-security/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.
+
+## Cadence
+
+We aim to create a new major release of the Panfactum stack **twice per year.**
+
+We **strongly recommend** that users of the Panfactum stack update their major version **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.
+
+## 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
+
+**We offer extended support and enhanced resolution SLAs to [our customers](../../../pricing).**