My solution times out against the random tests too every time (Kotlin).
On my computer even for very long arrays it completes in under 1 second :(

Kotlin test cases:

input string: "10001010111110001000011110011100"
vs.
"You can assume that all inputs are valid."

What is the expected output of this?

Kotlin random tests seem to contain Integer overflows in their expectations, causing valid solution to fail.

If you catch III II I, why you don't catch XXX XX X, but only X. And not CCC CC C, only C. Also not MMM MM M, only M.
For more readability you can delete .replace("III", " 3 ") and .replace("II", " 2 ")

Ok, sincere apologies, you were correct, I reopened the issue at the top of the page. the tests are indeed using reflection, i dont know why your code is failing

My code supports the entire history of versions.

For example assertEquals("0.0.1", VersionManager().patch().patch().rollback().rollback().release()) holds.

Also what do you say to the test error message which states that a method call has been returned?
Pretty sure looks to me like some reflection issue.

the description could make it clear that rollback() has to support the entire history of versions, not just the last version

okay, i checked your code, you made the same mistake as me initially, rollback() has to support the entire history of versions, not just the last one. i think the description should make this clearer

Ok I completely read over that part. Perhaps because of all those capz.

The input will be in one of the following formats: "{MAJOR}", "{MAJOR}.{MINOR}", or "{MAJOR}.{MINOR}.{PATCH}"

This implies that major and/or minor are optional.
That anything after patch should be ignored can be viewed as a convenience (i.e. "we have the values we need, anything else doesn't break things so we'll just silently ignore it").

that's the thing with input validation in kata's, either it should be very clear, logical and consistent, or you should not have to deal with validation at all; this is in between, which is messy

i'd add that converting from an empty string to a default value, while there is already an overload / default argument to handle the case nicely, is awkward

I don't really like the argument validation. 1.h is an expected error, but 1.2.5.h is not. At least, that is what I make out of the spec.

• Why is noice after 3 apparent version numbers ok, but not after 1?
• I don't see the spec mentioning Minor and Patch are optional arguments.

please tag this as a question, not an issue. it is very likely that the error comes from your code, not the tests suite, as 160+ people passed the Java version without complaints. are you making sure that your methods are chainable ?