Is this common to add a "changelog" like this to PHPDoc? And now we also have three @since and no @version anymore. 🤔

I guess we used the @version wrong, if I am right, it is ment to set versions for APIs and similar (https://docs.phpdoc.org/guide/references/phpdoc/tags/version.html#version), and you can use multiple @since (https://docs.phpdoc.org/guide/references/phpdoc/tags/since.html#since)

Yep, @since is commonly used for changelog purposes, mostly changes to method signature or high-level behavior (at least helpful on public API that can be quite helpful to have this information on hand in the IDE)
@version is meant for semantic changes and the state of the functionality.

Multiple of either one don’t make much sense, because they yield barely any information, just “something was done here“.

Something like this would be more or less meaningful:

@since 1.0 introduced (if this is left empty, the natural assumption would be the same)
@since 1.1 return boolean result instead of void
@since 1.2 make parameter $foo optional with default 42

@version 1.1

I personally often omit the version tags, if there is no real need for that. The since-tags often help even in the same project to see why a method is used in a non-optimal way or similar. In such cases the hint “method was updated in 1.2“ and “we use it since 1.1“ immediately presents a valid reason, so we don’t have to guess what someone may have thought here.

Btw. that is also done in WP core and the changelogs are rendered in the reference articles, e.g.: https://developer.wordpress.org/reference/functions/wp_parse_url/#changelog

"Since" we only use it on some functions and we don't even have a real "public API", would we even mind keeping these @since version numbers up to date?

Well, a public method is a public method and there are some recommendations out there for things like workarounds or custom triggers that call some of these. Some snippets given by ourselves in the support forums. Documenting API changes enables users of those to potentially migrate their logic without opening another support request, if changes are not self-explaining.

I agree, the majority of our code is designed for internal use and only exposed public for hooks etc.

But as with every project, that’s yet another part of documentation that might get out of sync over time. Though it’s probably one of the easier parts, as old annotations typically never become wrong, so we only have to append another one-liner, if necessary.

Do I get this right, that you first create a table with empty <tr> tags and then fill/replace them using JavaScript? Why not generate the <table> in JavaScript instead?

OK, you do just the same as with the other tables 🙈