You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would have expected "38m57aa" to get parsed as a component, not a set of components.
It seems like scala-steward already knows that the dot character is a separator, it just doesn't know that "38m57aa" is a githash.
The component parser does have a sub-parser for "hash", but it's unclear whether this particular substring matches that pattern. I'm not familiar with the cats parser syntax, so I can't really interpret whether this is desired or a defect.
Even if this particular case was parsed "correctly" (by my interpretation), what happens when the githash component starts with a b or m or ea?
The text was updated successfully, but these errors were encountered:
This allows hashes to also be separated with a `.` and `_` from the
preceding component.
Here is for example what `Version.Component.parse("1.0.0+1320.38b57aa")`
returned before this change and what it returns now:
```
before:
Numeric(1), Separator(.), Numeric(0), Separator(.), Numeric(0), Separator(+),
Numeric(1320), Separator(.), Numeric(38), Alpha(b), Numeric(57), Alpha(aa)
now:
Numeric(1), Separator(.), Numeric(0), Separator(.), Numeric(0), Separator(+),
Numeric(1320), Separator(.), Hash(38b57aa))
```
Btw, recognizing hashes was added in #1549 but that PR gives no
explanation why they only could preceded by `-` and `+`.
Closes#3124
Turns out this issue has a simple fix, namely allowing . to precede hashes, see #3260. We currently only recognize hashes if they are preceded by a - or +-
Hi, I hit an interesting case recently which I believe boils down a possible issue in Version.Component.parse (hence the title).
Say I have the following versions:
The version suffix consists of a monotonically increasing build number and a githash.
I would expect
currentVersion.selectNext(List(nextVersion)
to returnSome(nextVersion)
.However, it actually returns
None
.When I looked into this more, it turns out that this is returning
None
because of how nextVersion is parsed:returns:
Crucially, the segment
.38b57aa
is parsed into five components:Separator(.), Numeric(38), Alpha(b), Numeric(57), Alpha(aa)
Calling
Alpha(b).order
returns -4, because this component is getting interpreted as a "beta" component, at this line: https://github.com/scala-steward-org/scala-steward/blob/main/modules/core/src/main/scala/org/scalasteward/core/data/Version.scala#L171C5-L171C5So then the
nextVersion.minAlphaOrder
returns -4, causing it to get filtered out at this line: https://github.com/scala-steward-org/scala-steward/blob/main/modules/core/src/main/scala/org/scalasteward/core/data/Version.scala#L70This turns out to be the case for any first containing substrings
m
,ea
,rc
, etc.For example, this ends up printing None:
Some thoughts/observations:
I would have expected "38m57aa" to get parsed as a component, not a set of components.
It seems like scala-steward already knows that the dot character is a separator, it just doesn't know that "38m57aa" is a githash.
The component parser does have a sub-parser for "hash", but it's unclear whether this particular substring matches that pattern. I'm not familiar with the cats parser syntax, so I can't really interpret whether this is desired or a defect.
Even if this particular case was parsed "correctly" (by my interpretation), what happens when the githash component starts with a b or m or ea?
The text was updated successfully, but these errors were encountered: