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 -- 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
