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 10.2.1.0 and 10.3.0.0  (Thanks
> for the fix BTW!)
> 
> It is in the Jira 10.2.1.0 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 10.3.0.0 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 10.4.0.0 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
10.3.0.0, 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 10.2.1.4 (?), 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 10.2.1.4.

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 10.2.1.0   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 10.2.1.0?

> 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.

Agreed,
Dan.


Mime
View raw message