Allow release versions such as v1.2.3 and release-1.2.3 (as well as other patterns recognized by composer)

[Ocramius]

Ref: #35 (comment)

[ntzm]

Should this be something that is dealt with in nikolaposa/version?

[Ocramius]

@ntzm yeah

[ntzm]

I opened an issue here: nikolaposa/version#12, looks like it won't be until 3.0 that it's considered

[ciaranmcnulty]

This is pretty important, AFAIK v1.2.3 was not only supported it was encouraged by composer, at least at one stage

[Ocramius]

Talked with @nikolaposa in person about this, and it will likely happen when he has time and willpower (PHP Serbia aftermath first)

[nikolaposa]

Support for v1.2.3 has already been implemented in /~https://github.com/nikolaposa/version/releases/tag/3.0.0 (15: Relaxed version parsing). I'll consider adding support for release- prefix for 3.1.0.

btw Are there any other prefixes besides v and release that would be worth considering?

[Ocramius]

Maybe @alcohol can answer that

[ntzm]

Looking through the composer source, seems it's just release- and v

[nikolaposa]

I mean, if I'm going to introduce that change, I would like it to be something that is not only Composer-specific, but more general, hence the question.

[alcohol]

Composer does not strictly follow semver formatting. If you look at /~https://github.com/composer/semver (specifically, the tests) you'll see it is very similar but there are a few deviations for legacy reasons. I think the v prefix is the only prefix we support. The release- prefix is not supported btw, but it is stripped for legacy reasons AFAIK.

[nikolaposa]

Version parsing was relaxed to supports both v and release- Composer-recognized prefixes in nikolaposa/version:^3.2.0 so I assume this one is fixed?

[Ocramius]

Still need a way to get the symbol name back though, as otherwise we cannot really run a git checkout command with a valid REF

[nikolaposa]

Got it. Can you refer me to some relevant places in code base so I can become more familiar with entire flow and how/whether Version is used in conjunction with other components, i.e. VersionCollection?

[Ocramius]

I think VersionCollection is only used during sorting, lemme dig up the relevant code location

[Ocramius]

This is where we need to preserve the original tag name: /~https://github.com/Roave/BackwardCompatibilityCheck/blob/master/src/Command/AssertBackwardsCompatible.php#L229

[nikolaposa]

Oh, I see the problem now. Versions retrieved from the repository are successfully parsed but their initial form is lost, so casting them back to string yields undesired result.

I'll see what I can do. 🤔 But everything suggests that I'll have to relax my strict adherence to semver.org and the idea that prefix is not part of the version number. Encapsulating that behaviour in a new object as I suggested here would make VersionCollection uselues for your scenario. This will be a fun weekend. :)

[Ocramius]

It would also break (pseudo-code) Version::fromString('1.2.3') == Version::fromString('v1.2.3'), so only ->equals() is viable now.

I also noticed an edge case: we could have duplicate versions (already happened in doctrine) due to v1.2.3 and 1.2.3 both being valid tags on a repository

[nikolaposa]

Something like this: nikolaposa/version@87ab652 could definitely solve the part with constructing and casting Version from/to string. But comparison problem would still remain as the $prefix is used solely for the purpose of preserving the original context.

[Ocramius]

Seems about right

[nikolaposa]

I'm not a huge fan of the idea of getPrefix() becoming part of Version public API, so as an alternative solution I could introduce VersionNumber that would be the SemVer-compliant object, and have the existing Version, with the same API + getPrefix() behaviour proxy to it.

That way I could avoid making some serious BC breaks, as Version behaviour would remain the same from the outside.

[nikolaposa]

I was thinking about v1.2.3 == 1.2.3 scenario. While it might be true that those are not the same versions, I have no idea what reasoning is valid in the case of other comparisons:

$v1 = Version::fromString('v1.2.3');
$v2 = Version::fromString('release-1.2.3');
var_dump($v1->isEqualTo($v2)); //false
var_dump($v1->isGreaterThan($v2)); //???
var_dump($v1->isLessThan($v2)); //???

If it's not equal, is it higher, is it lower? You can't really tell, because prefix does not carry any semantical meaning, unlike pre-release or build extensions for example that are compared lexically in ASCII sort order.

[Ocramius]

They are equal, but don't have the same state, hence == doesn't work

…

On Sat, Dec 28, 2019, 23:29 Nikola Poša ***@***.***> wrote: I was thinking about v1.2.3 == 1.2.3 scenario. While it might be true that those are not the same versions, I have no idea what reasoning is valid in the case of other comparisons: $v1 = Version::fromString('v1.2.3'); $v2 = Version::fromString('release-1.2.3'); var_dump($v1->isEqualTo($v2)); //false var_dump($v1->isGreaterThan($v2)); //??? var_dump($v1->isLessThan($v2)); //??? If it's not equal, is it higher, is it lower? You can't really tell, because prefix does not carry any semantical meaning, unlike pre-release or build extensions for example that are compared lexically in ASCII sort order. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#37?email_source=notifications&email_token=AABFVEHO6KEENUWNCYLRJRLQ27HLLA5CNFSM4E2WQWWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHYTKTY#issuecomment-569455951>, or unsubscribe </~https://github.com/notifications/unsubscribe-auth/AABFVEDXNCEKGDQ5EGNWATDQ27HLLANCNFSM4E2WQWWA> .