Reapply prefer_strict_generators to our code once we start only supporting OTP28+

[elbrujohalcon]

Basically, revert fc5fb4f once we can write OTP28-compatible code 😃

[kivra-pauoli]

Is this one currently released? I'm getting it in my code, but I use OTP 28-. Wouldn't it be enough to put the inclusion in a ruleset behind a compile flag, for example?

[elbrujohalcon]

I think we can wait a bit longer. If we start applying this to our code, we will immediately have to to move minimum_otp_vsn to 28, I think.
I don't think that change is that urgent. I would wait until our support is 28, 29, and 30 and then I'll add it.
If people really wants to apply this rule they still can, right? They just need to add it to their configuration.

[paulo-ferraz-oliveira]

If people really wants to apply this rule they still can, right? They just need to add it to their configuration.

It's already included in _stricter 😄 and this was what I was mentioning. We shouldn't have it applied to the ruleset when OTP 28- is used to compile, so maybe ifdef elvis_core's code around it (?)

[elbrujohalcon]

I still prefer to just wait, instead of -ifdefing around.

[paulo-ferraz-oliveira]

I might not have been clear - the issue is that elvis_core is flagging code (consumer code), in OTP 26, that we literally can't change.

Are you suggesting that anyone using rebar3_lint with the erl_files_strict ruleset just needs to toggle that rule off for now?

[elbrujohalcon]

I thought that the ticket was about reapplying the rule to our code. Which is something I think we should not do just yet… only after OTP28 becomes minimum_otp_vsn.

Are you suggesting that anyone using rebar3_lint with the erl_files_strict ruleset just needs to toggle that rule off for now?

Yeah. I don't think that's a big deal.

But I agree that we can make the rule not apply on OTP26. But in that case I would 100% not implement that with -ifdef(…).. I would implement it by checking erlang:system_info(otp_release).

[elbrujohalcon]

I still think that we should reapply the rule to our own code. So, @paulo-ferraz-oliveira : Do you mind opening another ticket to make the rule aware of OTP versions? We can include that one in 5.0.0. It should be very easy to implement.

[elbrujohalcon]

As a matter of fact, I'll have to apply the same logic to #571 … I might just go ahead and fix that thing, too… in there 🤫

[paulo-ferraz-oliveira]

I would 100% not implement that with -ifdef(…).. I would implement it by checking erlang:system_info(otp_release).

Potatoes, tomatoes?

[paulo-ferraz-oliveira]

#604