Thanks Mark for opening this discussion, it's very useful.
Indeed, by reading https://www.mediawiki.org/wiki/MediaWiki_1.20
would think that nobody has been done in 1.20, except perhaps some
localisation work. :p
I also agree that https://www.mediawiki.org/wiki/MediaWiki_1.18
good example to follow.
On RELEASE-NOTES: it *might* be comprehensive enough (quite often things
get forgotten), but in my experience it's completely useless to
understand what are the really important things, unless one is looking
for something in particular (which is, IMHO, the point of release notes
besides big deprecation warnings and so on).
The /wmfX subpages are perhaps even less useful, as they're just list of
commits for now (crucial, but not for all users), although I see that a
section "The biggest changes" has been added (mostly empty it seems?).
Scanning a dozen sub-releases makes one lose the overview of the really
important things anyway.
I don't know if free-form tagging in gerrit will solve all our problems,
but for now I can't think of anything better than adding a short note to
It doesn't need to be more than a [[gerrit:12345]] link, or a link to a
topic on gerrit, or whatever. People caring about the page will look for
more information later.
When you have that pleasing feeling "hurray my new awesome
feature/long-waited-for bugfix has been merged", adding a link to a wiki
page should be too much of a burden I think?
A simple thing that many software projects have and we seem to be
missing is an automatic list of bugs fixed in a release: we only have
target milestones. This means that:
1) your only option are release notes, which can be forgotten quite easily;
2) sometimes a bug is fixed in a branch but not in the main release and
we have no way to tag it as such.
Finally, we should perhaps also add some information on the main
extensions, especially the ones bundled in the release?