Our release notes process is quite straight forward.
New release notes go to RELEASE-NOTES file, and after
releasing a new major version, they get moved into
HISTORY and a clean RELEASE-NOTES is created.
The linear history is easily preserved this way.
However, there's a kind of changes which doesn't have
an exact addition version. Changes that deserve backporting
are done into trunk, then backported by merging with the
supported releases. The RELEASE-NOTES of those versions are
updated in a "Changes since xyz" heading.
However, it is not clear where that release notes should go
on the HISTORY file. Specially since it is no longer linear.
Currently, we could have a revision go into 1.15.6, 1.16.1
and 1.17.0. At which point should it be placed?
Old versions (up to 1.5.x) do have entries for updates in HISTORY
file, and also 1.13.x, but that's it.
We don't seem to be maintaining it, as brought up in r72587.
What should be the procedure when backporting?
* When merging to an earlier release, the RELEASE-NOTES go there,
and is added into trunk HISTORY file at the same time.
* When merging to an earlier release, the RELEASE-NOTES go there.
On release, the new section is added as a whole on the trunk HISTORY.
* We don't keep HISTORY for release updates. Changes get an entry inside
the branch RELEASE-NOTES, but also inside the trunk one. It is shipped
as a fix on the next major, even if it was also fixed in some minor
in-between.
The last one is the lazier one, and completely avoids the
on-which-version issues.
However, it can't cope with problems that are only fixed in the branch
(eg. a minor
fix for a feature that was completely rewritten in trunk). It also
delusions users
as giving fixes that they (should) already have.
I would prefer one of the other two, and perhaps give a common entry on
HISTORY
"Bug fixes in 1.15.x and 1.16.y".
Opinions?