> On 17 Feb 2015, at 10:34, Eelco Dolstra <[email protected]> wrote: > > Hi, > >> On 16/02/15 19:53, Ertugrul Söylemez wrote: >> >> Software should be fully documented. If you don't know where the line >> between "regular users" and "advanced users" is, don't draw one in the >> first place. > > It's not so much a question of regular vs. advanced use, but whether something > is a stable interface. If we document a command like nix-store > --register-validity (which is mostly a hack to support the nixos-install > bootstrap), we'd pretty much commit to supporting it in the future. If it's > undocumented, we can change or remove it in the future. > There is another option sorta in the middle, where you can list the command/feature/tool as "tech preview" in the release notes (and possibly also in a warning on the feature page), which basically means the feature is provided as-is and might change without promise of backwards compatibility. Companies normally use this mechanism when customers are screaming and shouting for a feature that they don't have time to stabilize, so they release it in an early access version for the early adopters but make no promises of full support or stability. Not sure if this approach is relevant here, but it does exist and is acceptable at least in the enterprise world :-) > -- > Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/ > _______________________________________________ > nix-dev mailing list > [email protected] > http://lists.science.uu.nl/mailman/listinfo/nix-dev
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
