db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Release Notes
Date Fri, 08 Sep 2006 22:58:42 GMT
Kathey Marsden wrote:

> Daniel John Debrunner wrote:
>> I'm not sure, I was just trying to understand your reasoning as to why
>> bugs fixed in the code line would be excluded. The last release seems a
>> reasonable approach.
> 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
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=11187&styleName=Html&projectId=10594&Create=Create
> (That makes sense to me)
> It is in the release notes
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12310800&styleName=Html&projectId=10594&Create=Create
> (That doesn't make sense to me)
> 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?

That's a good question, and I think it's more related to how version
numbers are handled and release notes generated. The Jira tracking
system should contain the correct information, and then work from that,
not make Jira incorrect to suite the release notes process.

Here's my logic for the fix in. When I fix a bug in the trunk I execute
sysinfo to see what version is says. So today for DERBY-1809 it says, so that's where it is fixed, and that's how I mark Jira.
Then if on Monday I merge it into the 10.2 trunk, I imagine sysinfo will
say (?), so ideally that's what I will add as a fix in. Of
course the scheme fails a little because there is no fix in for

I think also because this is an open-source project and anyone can build
off any codeline at any time for their own purposes, it makes sense for
Jira to be accurate, so they can look at what they have built and
determine the set of bugs fixed for them.

> My thought was that it should just be marked fixed   and then
> not show up in the 10.3 release notes at all.

How would we distinguish between a bug like that and one that has only
been fixed in

> I just don't at all understand what the Jira release notes mean the way
> we work it now.  I guess   the main thing that we document what our
> release notes mean.  If we use some other format and  the Jira release
> note mechinism doesn't mean anything to us, then we should probably make
> that clear somewhere too.


View raw message