Any plans for a 1.20.1 release for <https://github...

# detekt

[eygraber]

Any plans for a 1.20.1 release for https://github.com/detekt/detekt/pull/4723? It (hopefully) fixes what is blocking me from 1.20.0

[gammax]

How is this blocking you?

[gammax]

(i.e. is not a regression)

[eygraber]

For whatever reason most type resolution rules weren't getting run correctly pre 1.20.0

https://github.com/detekt/detekt/issues/4676#issuecomment-1088267221

[eygraber]

Is that a no?

[gammax]

I don't think we'll do a point release. This doesn't look like a regression. Right?

[eygraber]

Not a regression in the classic sense, but the issue is not present in 1.19.0 because the type resolution rules were not getting run correctly there (for me at least; more info in the github comment I linked). So 1.19.0 works, and 1.20.0 doesn't work.

[gammax]

So just disable those rule then no? They were not running before regardless

[eygraber]

I could do that, but they'd probably become the newest additions to my list of detekt rules that I've had to disable over the years, and re-enabling them got deprioritized. I'd rather that not happen 😅

Without the point release I guess 1.21.0 would be the next one, and I think the plan there is to enable a bunch of rules by default? I'm guessing that won't necessarily be the easiest update, and it would further delay me being able to update.

Also not that the project owes me anything, but I invested time in trying out the RC builds and reported a bunch of issues, specifically to avoid scenarios like this. Some of them got fixed and made it into 1.20.0, but others didn't. I think a point release is reasonable for issues that weren't fixed for the main release.

[chao]

• If you happen to have baseline setup in your project, you could keep those false positives in the baseline.xml.
• I also observed that type resolution was significantly improved in 1.20.0. Which is good but at the same time it may expose new issues like this.
I believe we are automatic the release process so that making a new release won’t be an expensive operation in the future.

I am not addressing your pain though, but just meant to give/confirm a bit more context

[eygraber]

I purposely don't keep a baseline for the same reason that I don't like disabling rules.

But I understand that creating a new release could be expensive. I mostly automated my releases like https://github.com/eygraber/portal/blob/master/.github/workflows/PublishRelease.yml

All I do is merge master into release and push. It's not that battle tested, but it's worked pretty nicely for me until now.

[gammax]

I believe we are automatic the release process so that making a new release won’t be an expensive operation in the future.

IMHO this has nothing to do with the release process. This is simply not a regression, therefore there is no point release needed.

I still don't understand why we would have to do a point release with this specific issue at this stage.

[eygraber]

What's the argument against making a point release?

[gammax]

We're making point releases only for regressions. This doesn't look like a regression to me.
Or am I missing something at this point? 🤔

[eygraber]

I was unaware that the policy was to only make point releases for regressions.

[gammax]

We follow strict semver. Therefore point releases are reserved for hot fixes

[eygraber]

According to semver , the only concern with PATCH releases is that they be backward compatible bug fixes:

1. MAJOR version when you make incompatible API changes,

2. MINOR version when you add functionality in a backwards compatible manner, and

3. PATCH version when you make backwards compatible bug fixes.