Improved package version handling #81
Description
The Package class only support a simple and single version string. This proves problematic in some cases where versions are composed of multiple segments such as with RPMs, Debs, http://semver.org and others. Versions comparisons end up also being quite specific to a certain type of package. e.g. the epoch RPM tag is an absolute ordering overriding versions and releases.
We should instead have a slightly more fleshed out version structure rather than having a plain string.
This version would hold a list of strings and provide a default representation and comparison behavior
Each package subclass could selectively override the way this list should be presented, compared or interpreted.
The version could be also be repsented as a component-level version or as a detailed package-level version.
For RPMs the build number shown in a release is not relevant from a component standpoint, but it is for packages, so a package could provide method to get a component or package-level versions.
Say an RPM would have: [version, release, os, arch, distro, epoch]
The function to provide a component Version returning the version (or the version could itself be broken down in more segments)
The package version function would return the join of (version, release, os, arch)
And then function to compare versions to consider the epoch if present and not 0
An NPM would have only, possibly broken down in semver segments:
[version,]
and would likely use the base Package code and not override anything.
So the Package class hierarchy would handle all kind of packages versioning scheme, with a sensible default
And the specifics of a certain package (say RPMs here, but I know of other cases for Maven Jars and Debs) should be specified and overriden for each package type if needed (in this case a different way to deal with package and component versions or comparison)