Started draft 4.0.0 release notes. Added table of API changes.

[dlmarion]

No description provided.

[dlmarion]

apache/accumulo#5527 details how I generated the APi changes. I figure these can be useful to determine what needs to be marked as deprecated for a 3.1 release and to help jog our memory on changes for the final version. The generated table doesn't look that great, so maybe we don't keep it in the final version.

[DomGarguilo]

I spun these changes up and things look good. The new API changes table is a bit confusing though.

A lot of the entries aren't really meaningful or are lacking details about what they are referring too. Also the SEVERITY and OLD column headers are not very clear to me.

Also since the table is so large the sections below it are sort of hidden. The table might be better off at the bottom as to not bury any other sections.

[dlmarion]

@DomGarguilo - Regarding the table,I agree it's not great. Maybe some css changes would make it look better? However, maybe it's not an issue. Talking with Christopher, he thinks that we should not put this in the release notes. I think capturing the differences will be useful though for our own internal use. It will be useful when working on the 3.1.0 release. I'm thinking that maybe I just remove the link in the release notes to the API changes file, and move the api changes file somewhere else in the directory structure.

[ctubbsii]

I'm not sure what will happen if we have an extra data file in the directory expecting release posts. Jekyll posts have specific directory layout conventions. I don't think this file should be here.

Also, while I don't mind generating a good report and publishing it at some linked place, I don't think it should be embedded in the release notes. Our release notes are supposed to be a human-readable curated set of what we think are the important things to know about at a relatively high level. Generated technical docs that show diffs in a tabular format is out-of-place, and subtracts from the user's ability to quickly get the highlights of the release.

Also, while the report is probably useful for us, to check our compatibility criteria for gating a release, I think it's probably not useful to a user for a major version bump. The major version bump itself already signals API incompatibilities, and the user's own code/build will be a much more reliable signal of what is incompatible than this generated report.