That would be better inline with the guidelines:

If a package is not a release but a commit from a repository, then the version part of the name must be the date of that (fetched) commit. The date must be in "YYYY-MM-DD" format. Also append "unstable" to the name - e.g., "pkgname-unstable-2014-09-23".

IMO we should just fix our tools (nix-env -qc) rather than give the package an incorrect name.

Ironically that will only be fixed in 1.12 and experimental :)

Merging, since people experience #30834. We can always revert as soon as everyone is on 1.12+

This is good because more people will likely update nix, but also @dezgeg has restored the compatibility of bcc with old nix in #31179.

For what it's worth, as a user who really likes the ideas of isolation and reproducibility involved in Nix (e.g. being able to roll back pretty much anything and easily uninstall if need be) but doesn't know much about how it actually works beyond the conceptual "treat package builds as pure functions"*, I'd love to see some way to choose both:

• Whether nix-env -q includes or does not include pre-releases (which may be inappropriate for unstable versions of packages but do have their place in my experience), and
• Whether nix-env -q shows the altogether latest version of a package or the latest within some range such as "semver major" (e.g. with NodeJS I am on the 8.x.y long-term support line for now and would like to see new releases of that version while ignoring the 9.x.y line until I'm ready for the bleeding edge)

But I'll admit to having a vague impression that even using the imperative CLI API on other OSes (e.g. Mac) the installed packages might be in some kind of "expression file" that I haven't yet looked for to see if I can specify version ranges (which would resolve the second use case)...

In the meantime, I came up with a workaround for the pre-release versions: nix-env -qc && nix-env -qc | grep pre | sed 's/[-0-9.]*[[:space:]].*pre.*//' | xargs nix-env -qa in place of nix-env -qc. Not pretty, but effective for that particular case!

*(Seriously, though, big shout out to everyone who's made Nix happen. The difficulty of being sure of what packages are doing in other systems has been a pet peeve of mine for years, and it's always fantastic discovering people already working with solutions to problems like that!)