nth-prime: Use object instead of bool for invalid value #969
Conversation
| "an error, or indicate a failure. Implement this in a way that", | ||
| "makes sense for your language." | ||
| ], | ||
| "version": "2.0.0", |
There was a problem hiding this comment.
This change should not cause the version to change to 2.0.0.
This opinion may differ from the documented procedure, see also: #938
There was a problem hiding this comment.
@Insti Ah, I missed that discussion. I'll make it a minor version update then.
There was a problem hiding this comment.
Should we not actually update the documented procedure before introducing deviations on a per-exercise basis?
There was a problem hiding this comment.
I'm going to pretend that this practice (of changing version numbers in contravention of the written meanings) disturbs me deeply and write this comment accordingly.
If we follow the written rules, even if we disagree with them, we at least know what each version change means.
Now that we are openly flaunting the rules, now we have no idea what each version change means. (It is possible they do have a consistent meaning, but the meaning is not written down)
I cannot* stand by this behaviour because I need my version numbers to have meaning. With these meaningless version numbers, my burden as a maintainer has increased unacceptably.
*: I actually don't care, since I don't have a track for which it matters in what precise way the tests were updated. Right now the only property I need to hold true is that the version changes in some way when the file changes... which I guess I could have achieved using commit shas.
There was a problem hiding this comment.
@petertseng @stkent @Insti What should I do with this versioning problem?
There was a problem hiding this comment.
Even on a track that uses not-generated tests, I don't really care about the difference between a major and a minor change, so I say move forward with this as-is and maybe separately open an issue to begin discussion of the current versioning guidelines?
There was a problem hiding this comment.
Because I said in #969 (comment):
I actually don't care
it is thus safe to proceed without asking for my further opinion.
But you asked anyway, so now I have to give it to you.
As I explained, I cannot accept any version change that does not correspond to a written versioning scheme that explains what a change in each component means. Either use 2.0.0 as the current versioning scheme would have it, or explain in writing the new versioning scheme.
There was a problem hiding this comment.
does not correspond to a written versioning scheme
Sorry, is the versioning scheme used here that written in #938 (comment)? It wasn't clear to me because that proposal says to remove the third component, which was not removed, so I rejected the possibility that it was that scheme.
Insti
changed the title
|
The actual change is good 👍 |
Insti
dismissed
their stale review
I'm not sure it's reasonable that this PR is being used as a version numbering scheme battleground. I'm fine with the change being meged but I don't 'Approve' of the major version chnage.
|
Discussion about versioning and updating the documented guidelines can continue in #938. |
This is more in line with how other exercises indicate error cases.