What's missing for 1.0.0 release?

[3flex]

What still needs to be done for 1.0.0 release?

Most detekt components are fairly mature. What a 1.0.0 release means is the API and configuration DSLs have to be locked down (see #1201 and semver.org).

Probably best thing is for @arturbosch @vanniktech @Mauin @schalkms (sorry if I missed anyone, just thinking about those who are heavily active) to:

• identify features missing for a 1.0 release
• confirm which components form part of the public API (detekt-api, detekt-cli, Gradle, others?)
• review the current API, create an issue for anything that needs adding/changing/removing
• track issues against a milestone or in https://github.com/arturbosch/detekt/blob/master/ROADMAP.md
• Use KDoc to document detekt-api
• publish documentation for public API (mostly done, except detekt-api)
• freeze public API
• anything else?

detekt is seeing wider adoption. A 1.0.0 release and adopting semver would be a great next step in terms of the tool's maturity.

[vanniktech]

I personally don't feel like Detekt is ready to be called 1.0.0. There are many false positives and open bugs/improvement tickets. Even nowadays APIs are breaking rather often. Probably because more people want it to be 1.0.0 and looking for inconsistencies - which is a good thing!

I suggest that we all go over all of the public API and try to get rid of all of its flaws and then give it some time to rest and gather feedback.

I'd also question certain features and their reason to exist. Like wrapping ktlint over detekt.

[3flex]

I think we're mostly thinking along the same lines.

Rule updates will always be required. New rules can be added in minor versions and false positives/bugs fixed in a patch version.

This issue isn't intended to say "call it 1.0.0, it's done", but to identity those key issues that are still open and to trigger a review of the public API as you said to prepare for a 1.0.0 release.

[schalkms]

I mostly agree with @vanniktech @3flex
However, I wouldn't want to remove the ktlint integration in detekt. I think the documentation should be more clear here.
I don't think there that many problems with the ruleset. Most of them are feature requests or related to type and symbol solving, which detekt lacks at the moment.

[schalkms]

Also thanks for bringing this topic to light @3flex

[3flex]

I think one goal should be to get detekt in a flexible enough state to run successfully on the KotlinConf Schedule Application. detekt should work with reasonable defaults doing nothing more than adding this to the root build.gradle file:

plugins {
  id("io.gitlab.arturbosch.detekt") version "1.0.0.RC9.2"
}

If it works properly in that project, it should work anywhere (it's a Kotlin Multiplatform Project with JVM, JS, Android and iOS targets).

[Mauin]

I agree with most of what has been said here so far. Looking at bugs in the core modules, raising test coverage and improving documentation. Also the amount of false positives in the rules need to be lowered and caught earlier. Possibly on CI we can integrate detekt into other projects and catch new false positives due to rule changes there.

However before releaseing a final v1 we should also have a roadmap for what is to come after v1 and think about which APIs those features need and what in the current API needs to change. This would allow us to prepare (possibly do backwards compatible changes earlier) and also think about good migration plans for users.

[arturbosch]

Hey sorry for a late response,
here is a list of things I consider needs to be done for 1.0.0:

• issues in RC12 are mostly done, needs review+merge
• under the 1.0.0 milestone I have tagged one open issue: Validate Configuration file before using it #516 - Validate Configuration file before using it
  • I think this one is critical as it has bitten some users already
• Build upon the default configuration #1248 this I consider as a must
  • mostly users copy paste the default config and make changes, a flag like --use-default-config-as-baseline could help here to have the yaml config being small
  • --fail-fast could also be a cli flag
  • both changes need better documentation as they are two different use cases:
    • use the default config as baseline (like ~40% rules are active) and override small parts
    • active every rule (100%) and override small parts
• I consider detekt-api, public parts of detekt-cli like CliArgs, the Baseline and YamlConfig and the gradle dsl / detekt extension as public api
  • KDoc for every file in detekt-api + UndocumentedClass/Function=active
• finalize our separator usage CLI should use consistent system-dependent path separators #1253
• Script: Compare detekt issues for same project with different versions #1338 is a nice have between releases, but not mandatory for 1.0.0, shortly after is okay too
• check detekt on KotlinConf Schedule Application as @3flex said

Edit: I think we should concentrate our work on delivering 1.0.0 for all detekt-modules. The gradle plugin can stay a RC and be released independently. For the gradle plugin we have some open issues which need more effort https://github.com/arturbosch/detekt/issues?q=config+is%3Aopen+label%3Agradle