See #1975, #1979, and #1983 for the long, bloody history of this conflict.

I took a look through all of the non-numeric versions currently in Spack. Here are the most common names:

 180 develop
  63 master
   8 xsdk-0.2.0
   3 head
   2 xsdk-0.3.0
   2 git (secretly the master branch)

There's a problem here. Aside from the 180 develop versions, all of these other versions are being sorted incorrectly. Currently, all non-numeric versions (aside from develop which gets special treatment) are considered to be older than all numeric versions. But does this actually make sense? Why would someone add a version control branch to Spack if it wasn't being kept up-to-date?

I'm sick of telling people to rename the version to develop even though it's the master branch. What if someone wants to add both develop and master? Do we tell them to expect concretization bugs with master and that there's nothing we can do about it?

In #8262, @bvanessen mentioned that he frequently uses @local during development with spack setup. Other people use @system for external packages. Currently, these versions are being sorted incorrectly.

I have two proposals that could be used to solve this dilemma:

1. Sort all non-numeric versions higher than numeric versions

I propose that we sort non-numeric versions higher than numeric versions. We would still install the newest numeric version by default, so there would be no change on the user-side. The only difference is that something like depends_on('[email protected]:') would consider master or head to be newer than version 1.2.

This proposal doesn't suffer from the problems mentioned in the aforementioned PRs, where there were complaints about having too much special logic.

2. Add special cases for master and friends

I first proposed this here, but we could have other aliases to develop that form a hierarchy like so:

This proposal has the added benefit that Spack would understand that develop is newer than master. It would also keep us safe from weird unexpected versions that aren't actually new, but from what I've seen these are rare enough to ignore. We could add additional aliases as we encounter them.

Precedes to reopen can of worms

@davydden @tgamblin