nixpkgs doc: version convention for pre-releases #26173
Conversation
| <literal>"pkgname-unstable-2014-09-23"</literal>.</para></listitem> | ||
| Also append <literal>"unstable"</literal> to the name — e.g., | ||
| <literal>"pkgname-unstable-2014-09-23"</literal>. | ||
| If the package is a pre-release snapshot, the version can reflect this instead |
There was a problem hiding this comment.
How do you know the next version number, if you are not the maintainer of the project?
There was a problem hiding this comment.
This can be applied only when the maintainers of the project clearly communicate the next version number and maybe I should clarify this but I didn't want to be too verbose. What do you think? Should I add the clarification?
In the use-case I have in mind (Coq), there is a clear communication on the next version with a roadmap, etc.
But in all the other cases, I'm very fine for continuing to apply the previous policy.
| @@ -254,10 +254,13 @@ bound to the variable name <varname>e2fsprogs</varname> in | |||
| dash) — e.g., <literal>"hello-0.3.1rc2"</literal>.</para></listitem> | |||
|
|
|||
| <listitem><para>If a package is not a release but a commit from a repository, then | |||
| the version part of the name <emphasis>must</emphasis> be the date of that | |||
| the version part of the name should be the date of that | |||
There was a problem hiding this comment.
Should this be SHOULD and the next line be MUST, for clarity's sake?
ref: https://www.ietf.org/rfc/rfc2119.txt.
There was a problem hiding this comment.
@a4d442663580 Do you mean, capitalized words?
If we want to follow this language recommendation for clarity sake then I would use "MAY" on line 261 instead of "can" and "MUST" instead of "should" on line 262.
There was a problem hiding this comment.
Yeah, that makes sense. The date is sufficient for a version. And I suppose the case for 1.0pre as described in L261 happens when the pre-release cycle spans over several weeks.
|
It sounds to me like this PR suggests that nixpkgs should make up release numbers for unreleased software. IMHO, that's wrong. I suggest to use date version when upstream does not provide a version number and never will. (Yes, some do that.) If upstream do have releases, but you absolutely want to package something that upstream doesn't consider ready yet, then use a "git describe" like format. That provides a way to relate the newer version to the latest release in a way that none of the other formats do. Adding "unstable" to the package name just means that now the package is disassociated from the original package. Why would we want that? I think the version number + optional lowPrio is enough and preferred. |
|
@bjornfor |
|
@FRidh That's not what the manual currently says:
And I interpret this part of @bjornfor's message:
precisely as saying that it isn't a good idea to give different base names to stable and unstable packages (when the two are available) and if the goal is to avoid spurious updates, then |
|
Closing because there is clearly no consensus to go in the direction that I proposed. |
See #26108.