Bump version to 8.0.0

[kallentu]

I tried my best with the CHANGELOG. Let me know if you'd want any changes!

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[parlough]

Looking at all the API breaking changes, shouldn't this be 8.0.0?

[srawlins]

After 7.0.0 I have been treating dartdoc as if it is all internal API; nothing public (lots of "public" API was broken in 7.0.1 and 7.0.2). That's not strictly true as we export plenty from libraries in lib/ outside lib/src/, so I guess step 1 would be to stop exporting from lib/. I'd be ok with either. We can call this 7.0.3 or 8.0.0.

[parlough]

I don't know how many developers use package:dartdoc but I think if it's going to keep being published on pub, its version should match what has changed. It's only fair to any potential users or even explorers of the package. I think they'd much rather have a major version that increases every release than pub solves upgrading them to incompatible dependencies.

If it's planned to discontinue publishing, do consider making this one final release as 8.0.0. Then adding to the README details about the discontinuation, publishing 8.0.1, then discontinuing it properly on pub.

If it's planned to just publish solely as a CLI tool, then consider making this one final 8.0.0 release with public APIs and then update to 9.0.0 and remove all exported APIs.

[srawlins]

I publish for customers to use it via dart run dartdoc. Flutter uses this to generate flutter.api.dev, and other customers can use it for a tool that updates with a higher cadence than the Dart SDK stable releases.

[parlough]

That makes sense and I know a few other cases of this use too. However that likely was not clear to many users, since it's not really stated anywhere apparent. Also the changelog previously tracked breaking library changes. So to transition to a world where that is clear, how about the following?

1. Release this version as 8.0.0, with a note that the next release will not be intended for use a library.
2. Update the version to 9.0.0.
3. Clarify in the README this package is intended for use as a CLI tool.
4. Stop exporting most public libraries (edit: or deprecate them).
5. Change libraries to our heart's content :)

[srawlins]

I think that's a fine plan. We can @Deprecate() the exports in the lib/dartdoc.dart ASAP as well. (It could be in 8.0.0, but Kallen is trying to get a release out to Flutter, so not high priority.)

[srawlins]

8.0.0 LGTM