Well, not so much as roadmap as a set of hazy directions received from an untrustworthy stranger and hastily scribbled down on the back of an envelope.
Generally speaking defect fixes will be given priority above things in the lists below. Releases will be pushed out following any major defect fixes, or when a reasonable number of interesting new features have been implemented.
Distributed testing. Early versions of PIT had working support for this using hazelcast. It had some minor issues, but was made inaccessible in favour of getting the basics
The code is still there, but has not been maintained as other things have moved on. It adds a great deal of complexity to the codebase and a decision
will need to be made at some point on whether it should be resurrected or removed entirely in order to simplify things. Original distributed code has been removed, when distribution is looked at again will probably be implemented via different strategy.
Some form of equivalent mutation detection. Not sure what approach would be taken, but there’s plenty of academic research in this area to draw on. Perhaps something fine grained that takes into account the type of the mutation operator.
Annotations to mark code not to be mutated. Possibly quite useful, but conceptually polluting your production code with a testing concern is wrong.
More intelligent block based coverage.
The line coverage implementation currently used by PIT is fairly basic, and could be improved in terms of both performance and the information it gathers. A block based approach would potentially allow PIT to target tests more
narrowly in some circumstances and also report partial line coverage. One obvious way to achieve this would be to use
a third party implementation such as JaCoCo (it would help if JaCoCo was available from maven central). The built in coverage system is now pretty efficient, outperforming cobertura by a significant margin. Work is underway to switch to work on a block basis.
There are a number of things within the code base that while functional and defect free are embarrassing, dirty or just plain wrong. These need to be polished, refactored, or re-written alongside the other work.