@citibeth @alalazo @adamjstewart : here is my quick solution (+31−20) to what we discuss in #1975.

This issue has clearly sparked passions. However, we are not ready for a PR because:

1. The conversation so far has taken place on the weekend, and certain parties have not yet had a chance to give their 2 cents.

2. The conversation is not yet over. For example:

   a) You brought up some points in your last message to which I have answers but have not yet replied (It's Sunday, after all). Topics include examples of -infinity and how version aliases can work without complicating things all over the place.

   b) There is no consensus on the idea that infinity should be represented as "develop" in our scheme (again; we need more time to hear from more people).

3. This PR addresses a feature, not a bug. Even if we had consensus and were all ready to go forward, we must be focused on bugs until after SC16.

For that reason, I'm changing the status of this PR to WIP.

This PR also does not involve the concretization algorithm, so I'm removing that label.

i am not saying we are ready, this is a PR to show how easy is it to add what i suggested. But I agree that it should have wip instead of ready.

@adamjstewart added the tiers you suggested.

@davydden I still don't see any need for 999999999999 anywhere in the code. Python classes allow you to override __lt__, __gt__, and all other comparison operators. These can be overridden with if-statements. What about something like this (this is half-way pseudo-code, so it might not work perfectly):

tier1 = ('develop', 'dev', 'latest')
tier2 = ('master', 'head', 'trunk')

def __gt__(self, other):
    if self in tier1:
        if other in tier1:
            return False
        else:
            return True
    elif self in tier2:
        if other in tier1 or other in tier2:
            return False
        else:
            return True
    elif is_numeric(self):
        if other in tier1 or other in tier2:
            return False
        elif is_numeric(other):
            return numeric_comparison(self, other)
        else:
            return True
    else:
        return False

I think your code does the same thing, but tries to do it by converting everything to a number for comparison. I agree that this is fewer lines of code, but is more of an abstraction. I think the point of this Issue is that we shouldn't have as many abstractions. My pseudo-code is a bit more direct, but I agree that it is more lines, and we would have to repeat something similar in other __lt__, __eq__, etc methods, which could be incorrectly copied and pasted.

It's possible that you could convince me that your solution is superior to mine. But can you replace 999999999999 with sys.maxint so that we aren't using magic numbers?

I noticed your recent edit. There's no reason that develop, dev, and latest can't all be equal. Although maybe that would cause confusion when printing spack info with ordered versions? I doubt we'll find a package with both develop and dev, but it can't hurt to be bulletproof.

I doubt we'll find a package with both develop and dev, but it can't hurt to be bulletproof.

exactly.

this is half-way pseudo-code, so it might not work perfectly

i will try adopting your approach soon... I agree that it's more clean.

@davydden Maybe make a second PR implementing my approach? I can see reasons why your current PR may be better in some respects and I want others to compare them.

will do.

@adamjstewart @alalazo: I don't have a strong opinion anymore on how many infinity-like strings we need in Version, so I will let @tgamblin or others with merge rights to decide. There are pro's and con's in both cases. I can fit the PR to either decision.

since @tgamblin said

I really don't want to add more than one special case

i will revert part of this PR to keep develop only (in a single commit). I can squash / drop it off any time.

@tgamblin :

I actually like @davydden's and @alalazo's idea to make develop function the same way as a version component as it does as a standalone version (sorry if I'm getting the credit wrong here).

I squashed this PR to do exactly this, i.e. 2.0 > 1.develop > 1.1

closing this one in favor of #1983, which I believe is a more elegant and robust solution.