@adamjstewart : how do I use that __gt__ operator in places like

for a, b in zip(self.version, other.version)
    return a < b

If you define __lt__, it is implicitly used when you call a < b. So basically, we would need to define all of the rich comparison operators. See https://docs.python.org/2/reference/datamodel.html#object.__lt__ for details.

This is the way Python does ordering internally. Python used to define a single behemoth __cmp__ that returned:

 1 if self  > other
 0 if self == other
-1 if self  < other

but this was deprecated and completely removed in Python 3 because it was deemed not flexible enough: https://www.python.org/dev/peps/pep-0207/

You'll notice that the Version class was already overriding __lt__ for this reason. __lt__ is actually what is called when you try to sort a list, which is why it's the most important. __gt__ is called when finding the max. But if you directly want to do a comparison like self.version > Version('1.2.3'), I think you have to implement __gt__. Please correct me if I'm wrong and it implicitly calls not __lt__ if __gt__ isn't defined.

So you should probably invert my __gt__ and replace __lt__ as it is now incorrect.

Almost made it work, just need to figure out 1 failing test...

@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).

Here is an alternative version which has several infinity-like versions: inf > 2.0 > 1.inf > 1.1 where inf is one of 'develop', 'dev', 'latest', 'master', 'head', 'trunk'. This is essentially @adamjstewart 's tier system.

As I said before.... if one magic version number is a problem, then 6 is a bigger problem. I know this is easy to implement, that is not the point.

if one magic version number is a problem, then 6 is a bigger problem. I know this is easy to implement, that is not the point.

how exactly is it a bigger problem?

@tgamblin @citibeth @alalazo @adamjstewart : I know that we are still to go back to discusion of version handling in Spack after v.0.1.0, but I suggest we merge this PR because in its current form it does not add anything else but 2.0 > 1.develop > 1.0 plus a minor refactoring of Version class to make it easier to read.

In all our discussion on versions, I realized that versions are a pretty trivial problem: only a finite set of version numbers are used for each package, and they are package-specific. That is... one package might have a version 1.3 while another one does not. So we're left with defining a (currently) complete order on a small and finite set of versions. Should be a trivial problem.

The insight from this was there is no need to spill so much ink over this issue, to get one "universal" way of numbering versions that will work for every package --- because there will never be such a thing. Versions are package-specific, and that needs to be reflected in the API.

I suggested a way to factor out versions that, IMHO, would be not very disruptive; see below from #1997 . I think it is the right first step to do on versions. After that, we can begin defining version schemes beyond the current default; for example, one that uses "develop=infinity" (or make it as a variant on the current scheme). Packages that want to use these new versions schemes can.

In short... I'd like to see versions get factored out, then I'd be happy to see this PR merged as an additional version scheme.

1. Since version schemes seem to be package-specific, that should be reflected in the Spack API. This will give us the flexibility we need to implement different versioning schemes, partial orders, etc: For example:
   a) Versions should maintain a reference to the Package to which they are related.
   b) New versions are constructed off of a Package (eg: Package.new_version() method).
   c) Comparison of Versions between packages throws an exception.
   d) Comparison of Versions belonging to the same package is delegated to a method on the Package. Eg:

class Version(object):
    def compare(self, other):
        if self.package != other.package:
            raise Exception(....)
        return self.package.compare_versions(self, other)

Of course, delegating this to packages doesn't solve the problem of how version schemes should work for 99% of packages that will use the standard scheme. But it does give us flexibility for the corner cases. More importantly, it allows the standard scheme to do package-specific things (based on, for example, what it finds in package.py or the Git repo).

This PR will break the current behavior of Spack; as far as I can tell, isdevelop('1.develop') will be False, it should be True.

One other thing about factoring out versions... there should be a Version.isrelease() method, which is used in concretization. (Currently, the method is called isdevelop(); the name and boolean sense should be reversed). This allows the concretizer to choose only release versions, in the absense of a specific request from the user to install a non-release version.

This PR will break the current behavior of Spack; as far as I can tell, isdevelop('1.develop') will be False, it should be True.

there is a unit test which pass 😄 so no, it does not break anything at all!

there should be a Version.isrelease() method

probably, but it's a different story.

OK, now I see that. But it will also give isdevelop('1.mydevelopmentnightmare.3')==True as well, which is inconsistent with the rest of the PR.

Please... factor out version schemes, and then submit this as a new scheme. There have been too many unintended consequences due to "easy" changes in Version.

But it will also give isdevelop('1.mydevelopmentnightmare.3')==True as well,

good point, fixed.

Please... factor out version schemes, and then submit this as a new scheme

I am sorry, but i do not have time or will to do so. Here I suggest modifications which I find useful, maintainers can always reject the PR if they don't see it fitting the goals of Spack.