LETTER_SUFFIX behaviour issue?

[lizmat]

I'm trying to implement the libversion algorithm in the Raku Programming Language, and have some test failures that I think are somehow related to my misunderstanding of the algorithm.

Looking at https://github.com/repology/libversion/blob/master/doc/ALGORITHM.md , it states:

Version is split into separate all-alphabetic or all-numeric components. All other
characters are treated as separators. Empty components are not generated.

10.2alpha3..patch.4. → 10, 2, alpha, 3, patch, 4

Then later it states:

A special case exists for alphabetic component which follows numeric component,
and is not followed by another numeric component (1.0a, 1.0a.1, but not 1.0a1). Such
alphabetic component is assigned a different rank, LETTER_SUFFIX, which follows
NONZERO (choice of this behavior explained below).

I don't understand why 1.0a1 is not included in this constraint, and 1.0a.1 is. They both split into 1, 0, a, 1 do they not?

So is this a problem in the documentation? Or the algorithm? Or the tests?

[AMDmi3]

So is this a problem in the documentation? Or the algorithm? Or the tests?

I don't quite get whether you see any inconsistency between documentation and the code or you're just asking why 1.0a1 and 1.0a.1 are treated differently. In the latter case that's because there's a clear intent to separate suffix from the following component. In practice (e.g. repologywide), it's encountered when additional components are appended to the version with letter suffix, such as 13.0a → 13.0a.20250919, and when that happens it should not change the way a is handled.

They both split into 1, 0, a, 1 do they not?

The important part is what documentation refers to as ranks. Though the values of components are indeed the same, ranks are different, as these versions are split to NONZERO(1), ZERO, PRE_RELEASE(a), NONZERO(1) and NONZERO(1), ZERO, LETTER_SUFFIX(a), NONZERO(1) respectively, and that significantly affects the ordering (1.0a1 = 1.0alpha1 < 1.0 < 1.0a < 1.0a.1).

[lizmat]

Thank you for your speedy reply! And I understand the intent. I just don't appear to understand the algorithm in that respect.

Ok, so if I understand your reply correctly, the sentence:

A special case exists for alphabetic component which follows numeric component,
and is not followed by another numeric component

applies to the components between non-alphanumeric separators before being split as described in step 1:

Version is split into separate all-alphabetic or all-numeric components. All other
characters are treated as separators. Empty components are not generated.

10.2alpha3..patch.4. → 10, 2, alpha, 3, patch, 4

So the approach that I'm taking in applying the LETTER_SUFFIX rule after the split of step one, is incorrect?

[AMDmi3]

When you do it is implementation detail. You can split, then classify components (but you'll need to preserve information on where separators were present). My implementations follow more effective single pass approach which does not require allocations, where string is parsed token by token, and this specific rule is handled with a lookahead

libversion/libversion/private/parse.c

Lines 115 to 137 in 16eda77

	if (my_isalpha(**str)) {
	++component;
	component->start = *str;
	component->end = skip_alpha(*str);
	if (!my_isnumber(*component->end)) {
	switch (classify_keyword(component->start, component->end, flags)) {
	case KEYWORD_UNKNOWN:
	component->metaorder = METAORDER_LETTER_SUFFIX;
	break;
	case KEYWORD_PRE_RELEASE:
	component->metaorder = METAORDER_PRE_RELEASE;
	break;
	case KEYWORD_POST_RELEASE:
	component->metaorder = METAORDER_POST_RELEASE;
	break;
	}
	*str = component->end;
	return 2;
	}
	}

https://github.com/repology/repology-rs/blob/1aa01c4eb0ef3592a8f5198aad3eeaa2a984890f/libversion/src/parse.rs#L91-L111

[lizmat]

If this were about efficiency, I wouldn't be doing in Raku :-)

But: understood. Still, it seems to me this is not the whole story: should 1.0pre-1 be ranked as non-zero, zero, letter-suffix, non-zero, or as non-zero', zero, pre-release, non-zero`. If the latter, why?

Thanks again for any feedback!

[AMDmi3]

The latter as it's a known keyword. Though it doesn't seem to be documented.

[lizmat]

Ah, that would explain. Will look in the source for the list :-)