On 17 March 2013 12:09, Luke Daley <[email protected]> wrote:
> > On 12/03/2013, at 3:54 PM, Adam Murdoch <[email protected]> > wrote: > > > > > > > > > On 13 March 2013 09:52, Adam Murdoch <[email protected]> > wrote: > > > > > > > > On 12 March 2013 02:12, Luke Daley <[email protected]> wrote: > > Hi all, > > > > We discussed this when we released 1.3, but I dropped the ball and it > didn't happen for 1.4. I also can't find any record of us discussing how we > want to solve this, but I have a recollection of the discussion. > > > > The core problem is that we don't specify anywhere what the issues were > with an RC that caused a subsequent RC. The information is in JIRA, but > that's not quite explicit enough. > > > > My idea at this stage is to just add some more smarts to the release > notes so that we can query JIRA for this info and display it dynamically. > We already pull the fixed issues dynamically so there is some precedent for > this. > > > > Do we need to be sensitive to the exact version that the release notes > are being produced for here? If we aren't sensitive to this, the release > notes for all RCs would list the known issues for all RCs. This is the > simplest thing to do implementation wise. The alternative would be to > detect at build time what the exact version is and conditionally include > code that checks for issues with RCs. I would prefer to avoid this as I'd > like to build the release notes the same way every time. > > > > Doesn't this mean that: > > > > - We release rc-1. > > - We find an issue and mark it as a known issue of rc-1 > > - We fix the issue and release rc-2 > > - The release notes for rc-2 show the issue as both fixed and known for > rc-2 > > > > The release notes for rc-1 would also show the same thing, I think. > > It comes down to how we want to think about the release notes… > > Are they (1) for the actual release, be that an RC or a final release. Or > (2), are they always describing the final release, but go through the same > snapshot, rc, final lifecycle? > > #1 means we need to generate them differently in different states, to > tailor the information. > #2 means they are always generated the same, and the information is the > same. > > So far we are doing #2. > > This would mean that the release notes for the RCs, and the final would > display: > > 1. Fixed issues > 2. For each failed RC, the issues > 3. For the final release, any issues discovered after the release > > 2 and 3 are similar but not the same. They need to be separate. > > I don't think we list fixed issues for an RC. That's implicit in the known > issues of the previous RC. > > If we stick with our current approach (#2 in the first list), in the > release notes we'd have: > > 1. Fixed issues for release (as we do now) > 2. Known issues for release (as we do now) > 3. For each RC that was not the last, each known issue > To be clear, this means "known issues that were fixed in the next RC"? I assume an issue discovered in an RC but not deemed important enough to fix would just go into "known issues for release"? -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
