On 17/03/2013, at 11:27, Daz DeBoer <[email protected]> wrote:
> > > 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"? Yes. > I assume an issue discovered in an RC but not deemed important enough to fix > would just go into "known issues for release"? Yes. > > -- > 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
