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.
