Support not SemVer versions

[juherr]

Sadly, everyone doesn't use SemVer but it could be useful to use jsemver in order to compare versions in the SemVer way.
In this case, a boolean isSemVer() method could be usefull.

[zafarkhaja]

@juherr could you please provide an example of what you mean by support of non-SemVer versions?

[juherr]

For some bad reasons, we use versions like x.y.zzz.aaa (ie: 1.0.002.001).

I looked for a library to compare such format but jsemver doesn't fit because refuse zero-padding (because SemVer don't).
I think a less strict option will permit to manage more format and use the comparaison of SemVer.

Maybe #14 will help.

[zafarkhaja]

Yes, looks similar to what was suggested by @fabianbuch in his pull request.

In addition to what I've said in the pull request, I don't think it's a good idea to support all the versioning systems out there, otherwise it wouldn't be a SemVer library anymore. What can be done within the scope of JSemVer is to provide some sort of adapters to convert to/from SemVer-compliant versions.

Though, this might lead to loss of version information

nonSemver = "1.0.002.001"
nonSemver.major == 1
nonSemver.minor == 0
nonSemver.patch == 002    <===
nonSemver.build == 001

// 1.0.2+001
semver = NonSemverAdapter.convertToSemver(nonSemver)
semver.major == 1
semver.minor == 0
semver.patch == 2         <===
semver.build == 001

// 1.0.2.001
nonSemver = NonSemverAdapter.convertFromSemver(semver)
nonSemver.major == 1
nonSemver.minor == 0
nonSemver.patch == 2      <===
nonSemver.build == 001

...unless you have a special rule of zero padding.

Also note that after conversion, the 4th number will be ignored when determining precedence, that is

1.0.002.001 == 1.0.002.002

Will such a functionality be ever useful, that is the question...

[juherr]

In fact, I am looking for a more generic library which can manage most of version patterns.
SemVer would be a bonus and a goal.

I think jsemver could be this library and there are some needs, but it's your decision. ;-)

[mwanji]

A partial non-SemVer support that would be really handy would be a String equivalent to Version.forIntegers (which could be rolled into Version.valueOf, I guess). It would accept "partial" versions, such as "1" and "1.0". Since this functionality exists for ints, it would be nice to have it for Strings, too.

[zafarkhaja]

@mwanji there is a subtle difference between Version.forIntegers() and Version.valueOf(). The former, one with 3 formal parameters (major, minor, patch), is an optimized version of the latter, that is if you need a simple version, say 1.0.0, you don't have to go through the whole parsing process. It's been overridden to have fewer parameters for the sake of convenience which, as it turns out, might not have been a good idea. The string passed to Version.valueOf(), on the other hand, undergoes the formal parsing process which has to abide to the formal grammar which doesn't allow optional major and patch versions. I've opened a discussion for this but so far the community seems to dislike the idea.

[mwanji]

I understand the resistance, but as you mention in the other issue, partial versions are allowed in comparisons.

This behaviour doesn't have to be in valueOf, but not having it at all forces clients to do some parsing of their own, for rather trivial reasons. In my case, I was parsing browser data from caniuse.com, and going from a version string that may or may not have 3 parts to one that does is fairly annoying.

[RobertFischer]

+1 for allowing partial versions in String parsers. I'm having to special-case those for parsing out REST API versions, which the users want to specify as the string, "2".

[zafarkhaja]

I'll be providing the support for partial versions with the next release (0.10.0).

[zafarkhaja]

As of 0.10.0 it will be possible to parse shorter versions, but not longer ones. Hopefully the next release will support this.