On 9/11/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:
I am content with this simple model: the Release Notes just describe the delta between the current release and some previous release. We're golden provided that the customer can trace an upgrade trajectory through that previous release.
+1, always a good idea to be explicit about what you are documenting and I think this covers all the necessary bases.
The tricky bit would be an oddball release like 10.1.7, which follows 10.2 in wall-clock-time but precedes 10.2 in upgrade-time. Who describes the delta between 10.1.7 and 10.2?
The answer is: whomever makes the 10.1.7 release, since they are the ones who have the information to describe the delta between 10.1.7 and the 10.1.6 (and any other - 12.17.x, 11.2.3.2, 10.3.x, etc.) releases that have already been made in the interim.
That is what I was hoping to do for 10.2: i) State in the Release Notes that we're only describing the delta between 10.1.3 and 10.2. ii) Then document that delta. Of course, as Kathey points out, this is easier said than done given the discussion about topic
I think the only change I would make to the above is that the delta is between 10.2.1.x and 10.1.3.1, since that's the latest official 10.1 release at this time. Since there are already changes merged (and marked in JIRA) as Fix In 10.1.3.2, you need that last digit in the version number to distinguish what you're documenting as being in the official release 10.1.3.1 as opposed to the as-yet unreleased 10.1.3.2 and/or 10.1.4.x. There's a discussion to be had there about when it's appropriate to bump the third part of the version, but I'm willing to save it for a later date. andrew
