Ok, new proposal: Whenever you make a change that does any of these: - Breaks backwards compatibility with existing user state (e.g. db versions etc) - Changes type of options - Changes semantics of options - Removes existing options
you should include a description of the change in the release-notes.xml. After a few of those we can figure out a template that works, and we can see about letting nixos-rebuild parse the diff. Wout. On Fri Dec 19 2014 at 3:15:59 PM Eelco Dolstra <[email protected]> wrote: > Hi, > > On 19/12/14 15:10, Wout Mertens wrote: > > > We already have a place to document breaking changes, namely the > NixOS release > > notes in nixos/doc/manual/release-__notes. I'm not in favour of > having multiple, > > out-of-sync locations to keep this info. > > > > > > Right, but those are not very human-readable nor is there any attempt to > make > > them machine-parseable (for displaying diffs from nixos-rebuild and > tests). > > It's probably a lot easier and well-defined to generate something from XML > than > from some poorly specified, ad-hoc Markdown-like language. > > -- > Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ >
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
