From cb89165fb9a5e80a05356af4d75ed826d7d417e0 Mon Sep 17 00:00:00 2001 From: OPNA2608 Date: Thu, 11 Jan 2024 17:40:24 +0100 Subject: [PATCH] pkgs/README.md: Clarify versioning on projects lacking proper releases --- pkgs/README.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/pkgs/README.md b/pkgs/README.md index 0649d9415a26..f614f1f72976 100644 --- a/pkgs/README.md +++ b/pkgs/README.md @@ -354,6 +354,10 @@ There are a few naming guidelines: Example: Given a project had its latest releases `2.2` in November 2021, and `3.0` in January 2022, a commit authored on March 15, 2022 for an upcoming bugfix release `2.2.1` would have `version = "2.2-unstable-2022-03-15"`. +- If a project has no suitable preceding releases - e.g., no versions at all, or an incompatible versioning / tagging schema - then the latest upstream version in the above schema should be `0`. + +Example: Given a project that has no tags / released versions at all, or applies versionless tags like `latest` or `YYYY-MM-DD-Build`, a commit authored on March 15, 2022 would have `version = "0-unstable-2022-03-15"`. + - Dashes in the package `pname` _should_ be preserved in new variable names, rather than converted to underscores or camel cased — e.g., `http-parser` instead of `http_parser` or `httpParser`. The hyphenated style is preferred in all three package names. - If there are multiple versions of a package, this _should_ be reflected in the variable names in `all-packages.nix`, e.g. `json-c_0_9` and `json-c_0_11`. If there is an obvious “default” version, make an attribute like `json-c = json-c_0_9;`. See also [versioning][versioning].