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 As this info is dynamic and generated when the release notes are viewed, it would look the same for release notes for the RCs and the final release. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com Join me at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
