RoadMap

[gleclaire]

A roadmap for spotbugs should be posted to allow users, plugin developers, detector developers, and others to see where we are heading.
This will be useful for Findbugs users looking to plan and change to Spotbugs.
In my time on working with the Maven and ANT plugins I noticed some items I believe we need to keep in sight going forward to keep our current users and attract new users.

The configuration of a Findbugs job varies depending on the interface (i.e.command line, ANT, or eclipse, intellij, or maven) used. This can lead to differing outputs a developer may see in their IDE and what a build server presents running maven, gradle, ant or sbt.
I have tried to follow the the command line set up since looked like the common mechanism used but the creator and the course at UMD ( University of Maryland). This had its short-comings, as the documentation to that has been incomplete.
As a useful tool for continuity between sub-projects and migration from findbugs the main project should have classess and interfaces for conversion between include/exclude config files for spotbugs. This will make it easier for IDE to be configured to match build setups.

[iloveeclipse]

Roadmap is a good idea. Wiki page? I've just enabled "Wikis" for the project, so we can start to add items.

[iloveeclipse]

BTW we have "Milestone" thing on the right side in Github. There is already 4.0.0 milestone, so is this not enough? Just playing the devil advocate. The benefit of this Milestone thing is that one can see the state and the state updates automatically while tasks are added or fixed. The information on the Wikis tend to become obsolete pretty fast and need constant manual updates.

[henrik242]

I agree, the Milestone tag should be enough as long as we're tagging issues properly. And maybe add "epic" issues for larger things we want to do?

[iloveeclipse]

However the benefit of Wiki is that we can put there some generic ideas, where a task would be too concrete and no task would be too less :-). Also I think a wiki with the "Roadmap" title is easier to find as the "Milestones" thing. Wiki can point to the milestones anyway, but providing some more information who plans to do what, highlight "bigger" stories etc.

[gleclaire]

RoadMap can be more generic and cover the umbrella of projects(spotbugs, gradle plugin, maven plugin, etc). The milestones for each project will have specifics for any milestone item it is involved with.

[KengoTODA]

I agree to use wiki for organizing roadmap, at least draft roadmap. And about Epic, I hope label or project is enough for this usage.

I've gathered issues in 4.0.0 milestone, and make a draft roadmap at https://github.com/spotbugs/spotbugs/wiki/Roadmap

[KengoTODA]

No update for that roadmap? Feel free to edit that if you have idea about what you want to introduce at 4.0.0 release.

[KengoTODA]

Recently I changed my mind about 4.0 release; I think that we need refactoring firstly, especially to make object lifecycle clear. Then I want to start from "Support JSR330 and JSR250 for detector (e.g. use @Inject for BugReporter and AnalysisContext)" with dagger2 or other fast DI system.

[KengoTODA]

I feel this issue has no meaning at all, we have no continuous contributor who make the progress. 😭