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. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.com
