Open Tenga opened 3 years ago
How about use >=5
How about use
>=5
Hi! Thanks for the response.
As I mention in the issue itself, I'm aware that to get the intended result of the intent "when major version is higher than 4" is to write >=5
.
What I am trying to raise is the following:
If there was a poll to ask the following two questions:
// TODO [got@>11]: Change A to B
mean?// TODO [got@?]: Change A to B
, what would you replace ?
with to have the linter raise the issue when major version of got
is higher than 11?I am currently under the impression that the answers to that poll of those who answer instinctively, without checking, might be:
got
to 12.0.0
">11
"And those would not be the correct answers as it currently stands. Granted, my impression might be wrong, as I'm basing it off of asking those questions to a couple of people, and I've found it that the answers are the ones above, but I felt like it was worthwhile to raise it as a potential issue.
It's an minor annoyance, that I feel the people using expiring-todo-comments
can fall into, due to instinct as to what a partial version number means.
I'm just highlighting the potential to maybe address this potential "instinct issue" at some point, if the maintainers agree with my assertation above.
No hard feelings if we don't agree, and am open to have my mind changed on that opinion.
Hi maintainers. 👋
First off, thanks for developing and maintaining this package, it's been really useful!
However, I have a minor unintuitive nitpick with how the
expiring-todo-comments
rule handles partial versions.The problem
To preface:
>
and>=
, and a "valid SemVer version" is expected after the comparison operator.However, I believe, there is a minor unintuitive case here where versions that don't specify all three positions.
When reading/writing the TODO comments and encountering or writing
>4
, my brain goesand same goes for
>4.1
where it goesHowever, what this really means is:
>4
is actually>4.0.0
due to coercion, which will get triggered by any version higher than4.0.0
>4.1
is actually>4.1.0
due to coercion, which will get triggered by any version higher than4.1.0
>=4
is actually>=4.0.0
due to coercion, which will get triggered by any version higher than4.0.0
, including4.0.0
>=4.1
is actually>=4.1.0
due to coercion, which will get triggered by any version higher than4.1.0
, including4.1.0
This can be avoided by suppressing my own monkey brain:
>=5
or>=4.2
>4.9999.9999
or>4.1.9999
but ... yeah, no.One might argue that even the documentation gets this wrong. It's a bit hard to assume the intent here due to missing context but I believe I can assume the context, so I am using them to support my assertion of unintuitiveness by showing the problems the examples have.
The examples that are currently here state:
First example will always trigger at any version other than
0.0.0
.>=1
as we assume allv0.x.x
are unstable in SemVer and that the author will have multiple unstable versions like0.0.1
and0.0.2
and the first "stable version" isv1.0.0
or greaterThe second example will trigger on
10.0.1
and higher, while the intent seems to be to say>=11
.9.x.x
range then the "next major version" intent fails because10.0.0
won't trigger the rule, therefore it should be>=10
10.0.0
, then the "next major version" intent fails as it will trigger the rule even on10.0.1
10.x.x
(excluding10.0.0
), then it will trigger right away while we're still in anyv10.x.x
range and the "next major version" intent fails.Of course, there are other examples that reason about this correctly, but these two seemingly don't, and it's understandable why.
Potential proposed resolutions
Do nothing
I mean, nothing is really wrong here, it works as underlying logic would dictate. It's just a bit unintuitive, and when writing such comments, I shouldn't really assume
4
expands to a range4.x.x
but to version4.0.0
specifically.Readme examples might need correcting, if my assumptions on them are correct.
Presume that missing minor/patch places imply a range
This would fix the assumed unintuitiveness in this specific case, but would probably be a breaking change to the rule.
Even the support for explicitly setting X-range (
1.x.x
,1.1.x
) version seems like it would be a breaking change as they also currently get resolved in the same manner. The lack of intuitiveness here would remain unless the support for partial versions is also removed to prevent it.I don't believe this is quite a bug or a new rule, but I believe it's closer to a bug, so I've created it as that.
Also, apologies for any premature issue notifications, opened the issue prematurely by accident. 😓