coding-conventions: include the preceding upstream version#234201
coding-conventions: include the preceding upstream version#2342017c6f434c merged 1 commit intoNixOS:masterfrom
Conversation
rhendric
left a comment
There was a problem hiding this comment.
This is better than what we have and so I support it. (Should probably use English quotation marks and not guillemets, but that's completely superficial.)
a9d2f9c to
f1db774
Compare
f1db774 to
5b90f7a
Compare
…ging a commit without a version attached
| - If a package is not a release but a commit from a repository, then the `version` attribute _must_ be the date of that (fetched) commit. The date _must_ be in `"unstable-YYYY-MM-DD"` format. | ||
| - If a package is a commit from a repository without a version assigned, then the `version` attribute _should_ be the latest upstream version preceding that commit, followed by `-unstable-` and the date of the (fetched) commit. The date _must_ be in `"YYYY-MM-DD"` format. | ||
|
|
||
| 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"`. |
There was a problem hiding this comment.
or 3.0 and to know that for sure you would need to inspect the git tree. If upstream is using multiple branches to track releases that would not be that easy because the commit could be in both, so you would need to browse around the repo to double check things which is another burden for reviewers.
There was a problem hiding this comment.
It's not like a domain change, there are always small things where we can trust the patch author if everything looks sensible.
There was a problem hiding this comment.
I am running a lot into situations where authors do not set the version number correct and suggesting the old format is trivial while the new one requires several extra steps I need to take to make sure the suggestion is correct.
Under those conditions I cannot just trust authors to set this correct and I think having wrong information is more harmful than not having that information at all.
There was a problem hiding this comment.
Let's automate the work, then. It should be fairly straightforward to write a maintainer script that checks the Git repository for the most recent tag preceding a commit and edits the version accordingly, right?
|
So we closed the RFC now and that's the compromise? Also I didn't know about this until 5 minutes ago which is concerning because I am belonging to the group of most active people in this repo and didn't notice this reviewer relevant change for 3 weeks. |
|
Should we update |
|
Yes. It already has option for the previous proposal so it should be as easy as turning it on by default and tweaking the format slightly. |
Description of changes
The only thing that seems clear after all the versioning discussions is that we do want the previous upstream-assigned version in the beginning when packaging something untagged.
Things done
sandbox = trueset innix.conf? (See Nix manual)./result/bin/)