Neels J Hofmeyr wrote:
> Neels J Hofmeyr wrote:
>> Karl Heinz Marbaise wrote:
>>> Wouldn't it be better, based on historical reference to link to the
>>> CHANGES file into the appropriate release e.g.
>>>
>>> 1.1.html should reference .../repos/asf/subversion/tags/1.1.0/CHANGES
>>> 1.2.html should reference .../repos/asf/subversion/tags/1.2.0/CHANGES
>> (IOW make the 'CHANGES' link in site/publish/docs/release-notes/1.*.html
>> point at tags/1.*.0/CHANGES instead of trunk/CHANGES.)
[...]
> The trunk/CHANGES does include all versions' changes. Still, it would be
> good to not link to the collab.net repos anymore. (At least 1.1.html does that.)
Yeah, the great thing about always pointing at trunk is that it contains all
the change records, so if you want to see what happened in other releases,
the info is readily available.
The bad thing is that it contains all the change records, so if you don't
want to see what happened in other releases, you gotta dig some for the
release you do care about.
But here's my case for *not* linking against the tagged CHANGES items: we
only push out new release notes for big X.Y.0 releases, yet folks refer to
them as an explanation of what they are getting with any installation of
Subversion from the X.Y lineage. It would be weird to download Subversion
1.6.9, read the 1.6 release notes, and then get pointed to a quite-stale
1.6.0 CHANGES list. So if we're going to do anything around these parts, we
should be pointing to the CHANGES files as they exist in the release
*branches* (e.g. branches/1.6.x/CHANGES).
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-03-01 15:25:15 CET