mirror/nix-community.nixvim
1
0
Fork 0
mirror of https://github.com/nix-community/nixvim.git synced 2025-06-20 16:15:43 +02:00
Code Issues Projects Releases Packages Wiki Activity Actions 4

maintaining: initial "Releasing" section

Browse source
This commit is contained in:
Matt Sturgeon 2025-05-23 21:36:20 +01:00
parent 1350e87fa4
commit 2f610f9754
No known key found for this signature in database
GPG key ID: 4F91844CED1A8299
1 changed files with 24 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

24
MAINTAINING.md
View file

@ -5,3 +5,27 @@ This file is intended as a reference for Nixvim's core maintainers, although it
## Deprecation ## Deprecation
The deprecation policy discussion is happening in [#3181](https://github.com/nix-community/nixvim/issues/3181). The deprecation policy discussion is happening in [#3181](https://github.com/nix-community/nixvim/issues/3181).
## Releasing
Nixvim releases stable versions in sync with nixpkgs. A YY.05 version is released in May and a YY.11 version is released in November.
We do not need to wait for the release to be "stable" before creating a branch, however we _should_ wait before updating links and references on the `main` branch.
Creating a stable branch may require temporarily disabling branch protection. This can only be done by an "admin" or "owner".
Once a stable branch is created, its flake inputs should be updated to point to the corresponding stable versions.
The branch can be created before these exist, in which case they should be updated when the corresponding stable inputs become available.
Once a stable branch is created, it should be added to the `update-other` workflow on the `main` branch.
Once a stable branch is considered "public", it should be added to the `build_documentation` workflow on the `main` branch.
This can be done while the version is still "beta".
Once a stable version is considered "out of beta", references to Nixvim's stable branch should be updated on the `main` branch to reference the new version.
### Deprecating old releases
Once a stable branch is deprecated, it should be removed from the `update-other` workflow on the `main` branch.
It should also be removed from the `build_documentation` workflow on the `main` branch.