Out of interest, I'm a happy Detekt user since the...

# detekt

[dead.fish]

Out of interest, I'm a happy Detekt user since the early milestone releases and I was wondering if there are any plans to actually stabilize certain versions? I feel Detekt is moving quickly paced like ever before, so I have the fear that potential bugs / instabilities could lurk into it. Up until recently, I was using it mainly in small teams, so I could easily argue a version bump in case of an issue or fight this out myself, but now I basically want to throw it at a team of 30+ developers replacing Sonarqube (partially). Maybe I just missed to see an "official" notion on this topic anywhere, and maybe it's not so bad to move quickly and fix things after all, but on the other side new issues are easily introduced as well, and a static code analysis tool should be - first and foremost - reliable and stable in how it works and what it reports. So, tl;dr, will Detekt ever have stable, maintained versions?

[Brais Gabin]

Stable maintained versions? Do you mean a LTS? I don't think so.

[Artur Bosch]

So far we do not have the resources to maintain different branches but maybe in the future.
You could consider staying on the lastest minor version of a major version e.g. 1.3.1 or 1.7.3.
A good rule of thumb would be to use the detekt version which is used in the sonar-kotlin and IntelliJ plugins.
I mainly update them when I consider the current detekt major version stable.

[Artur Bosch]

At my dayjob I update the PMD versions every three months to the newest one and consider the new rules.

[dead.fish]

Due to several smaller issues I was staying away from 1.7 and kept at 1.6, thats why I was asking. It would be totally fine for example to adopt a tick-tock strategy like some projects do, i.e. have even numbers "stabilize" and uneven numbers are just versions that new stuff flows into quickly. At some point, when the dust settles, you just promote 1.7.xxx to 1.8.0 and start with 1.9.0

[dead.fish]

This wouldn't mean mainainting 1.8.0 anymore than you'd maintain current versions, just that 1.8.0 "aged" a little better than 1.7 or 1.5 aso.

[dead.fish]

And you could tell people who want the newest things "take uneven" and those who want stability "take even"

[Brais Gabin]

I think that if you want stability you can wait one month until the last patch version was launched. As you say detekt is moving fast for that reason the fixes arrive fast too.
I don’t know, I see stability problems in lot of major projects: Android Studio or Gradle for example. And using the rule that I told you before works like a charm with them.I think that we should not slow down the merge ratio or create complex branching.
I’m not saying that I don’t care about stability. It’s a real important thing but this tool is growing so we can’t stop merging things for the fear to break things. We work really hard on our test suite to spot all those problems before hand but if we change things, we broke things.

[dead.fish]

Absolutely right - but at least AS and Gradle have some kind of "alpha" period that is carried along the version number. You release 1.7.1 or 1.7.2 and it looks "stable" because there is no tag applied. How does little Joe know when "the month" is over (if it's really "a month")?