Things that absolutely must be done by March 30th, which is when I tag v2.0a1 on the main branch no matter what. That's because of promises for certain functionality that will be in the paper.

Everything here that's a feature/change is in the context of the new parser combinator code that's being added and not the existing monolithic classes.

• milestone: https://github.com/cclib/cclib/milestone/24
• paper: cclib 2.0 paper authorship and invite #1340
• parser combinators: Refactor parsers #335, A (light) refactor inspired by modern compiler theory #1124
• parser-in-parser: Support fragment calculations in some way #131, Support ONIOM calcs in some way #132, Support multistep jobs generally #657
• attributes as classes: Future of nmo, nbasis and similar attributes #99, Structure of future attributes #419

Things not promised in the paper but people should be prepared for, or they'll be angry if any of this is a surprise.

• atomic units w/ unit objects: Switch to atomic units #89, Units for parsed energies #998, Tag parsed data with units #1264
• testing: Fix testing for parser combinator infrastructure #1394

I think for the output units those changes can go into the existing infrastructure too, but on the main branch. When 2.0 is finally released, which is when all existing functionality is transitioned to the new parser combinators, we will switch the default branch from master to main.

cc @oliver-s-lee This is the basic roadmap you asked for in cclib/cclib-data#166 (comment). The full 2.0 IMO is polishing whatever's in the alpha, but we reserve the right to keep adding API-breaking features, and there is no hard deadline for the final 2.0 release.

Please add stuff I am forgetting.