I am only aware of nixos release notes. However, as a “rolling release” distro, we have software version updates and nixos module changes (especially breaking ones) quite frequently.
Because of such breaking changes, people may want to be notified about parts of nixos that they’re using, not all of them (like the big list in each os release note)
I can imagine a structured changelog provided with nixos that reflects all the software or module changes. Something like this:
- software nixpkgs.x: from v0.1 to 0.2 (nixpkgs git commit m to commit n): some note
- software nixpkgs.x: from v0.2 to 0.3 (nixpkgs git commit p to commit q): some note
- software pkgs.y: from v1.5 to 1.9 (nixpkgs git commit u to commit v): some migration guides
- nixos module foo.bar.bazz (from nixpkgs git commit r to commit s)
...
That changelog should be amended when:
- a PR gets merged to nixpkgs repo and the PR author has something say (it’s totally okay to have empty change note if it’s not a breaking change)
- a nixos maintainer submit such a change note. Especially useful when a breaking change is only discovered when people filing bugs.
People will then open a user interface designed to pinpoint to the change notes they’re interested in.
1 Like
Reading the source code is definitely helpful. I haven’t thought of that. Thank you very much.
That being said, I expect something richer. Reaching for the code takes time and can be intimidating when what one needs to do is only updating a piece of configuration (in other words, we’re requiring people to read code even in low-code situations).
Also, the code in a specific file is not the single source of truth. There are also:
- nix’s library abstractions outside that source file
- breaking changes from upstream
- reported issues in nixpkgs github repo
That’s why a graph database is handy in the use case I am imagining. I mean we can put the relations to the database. People can query (via a nice user interface) the parts they’re using, and get the best info we can provide regarding the nix pieces they care about.
At least it can help people sieving through reported issues easier and maintainers’ work besides code can be more accessible.
I am considering building a web interface for such database together with a worker (maybe better call it a bot?) that listens to commits and github issues in nixpkgs repo and update the database.
Inputs and opinions are welcome.
1 Like
This is my mockup for the web ui:
the result screen:
the optional local script:
Ideally all you need is an RSS feed to the next versions release notes because any PR causing incompatible changes is supposed to add an entry there. You can monitor everything from one file… in theory.
You made a good point there.
On second thought, though such ui can be handy, it will take a huge effort to build and maintain such a database. It may not worth it because people don’t get that many unexpected breakages where the benefit of quick filtering outweighs the cost.
Thank you all for your inputs. I surely have learnt a bit more about the nix way of doing things 
1 Like
