db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Meaning of Release Notes, was: Release Notes
Date Mon, 11 Sep 2006 15:26:20 GMT
The original thread seems to have split into at least three topics:

1) Should we bundle Release Notes with our zips? I believe the consensus 
was yes.

2) What does it mean to mark a JIRA as fixed in multiple releases? This 
topic has sparked a lot of useful discussion.

3) What issues should go into the Release Notes for a particular release?

I'm forking off a new thread to continue discussing topic (3). I think 
we want to end up with the following situation: If a customer leap-frogs 
several intervening releases, then the customer should be able to 
reconstruct the composite delta by studying the Release Notes for all of 
the releases along an upgrade trajectory.

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.

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? I don't feel we have to answer this 
question today but we should keep it in mind if we decide to issue an 
oddball release.

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 (2).

Please let me know if you think this is not adequate.

Thanks,
-Rick


Mime
View raw message