db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew McIntyre" <mcintyr...@gmail.com>
Subject Re: Re: Release Notes
Date Fri, 08 Sep 2006 21:48:29 GMT
On 9/8/06, Kathey Marsden <kmarsdenderby@sbcglobal.net> wrote:
> My reasoning for not marking multiple versions is that the fix ends up
> getting rolled up into the Jira release notes for the  next release.
> DERBY-176 for example  is marked fixed in and  (Thanks
> for the fix BTW!)
> It is in the Jira release notes
> It is in the release notes
> but it will not be in the release notes  presumably the fix
> implicit because it is fixed in 10.3, but of course it was really fixed
> in a previous release.  But why  should it be in the 10.3 release notes
> then?
> My thought was that it should just be marked fixed   and then
> not show up in the 10.3 release notes at all.

There's two problems that I see. One is that releases are not really
sequential on a time scale or even guaranteed to happen. A fix that
was made in 10.2 and merged to 10.1.4 will almost certainly be
released in 10.2 before 10.1.4. Wouldn't it make sense for 10.2 to
document the behavior, especially if it needs a proper release note?
In that case, it should really show up on JIRA queries for 10.2 issues
with the release notes check box. And what if 10.1.4 is never
released? If it is only documented as being fixed in 10.1.4 it will
never be seen in a set of released release notes.

The other problem that I could see is that the fix for the issue in
10.2 may not be the same fix that goes into 10.1 for various reasons,
because 10.2 may have changed significantly in the area of the fix and
so the fix may be implemented differenty, and it might require
different release note in 10.1 because the fixes are different. Having
it properly documented in both seems like a good idea.

That's why I tend to view Fix In in JIRA as datapoints that document
where - what branches - activity around the issue occurred, not when,
and why I think it would be advantageous in some circumstances to be
documented in more than one release.


View raw message