On 03/01/2013, at 11:16 PM, Luke Daley wrote: > > On 18/12/2012, at 5:35 PM, Daz DeBoer wrote: > >> On 18 December 2012 10:24, Luke Daley <[email protected]> wrote: >>> >>> On 18/12/2012, at 9:20 AM, Daz DeBoer wrote: >>> >>>> So are we thinking about a service that provides dynamic content into >>>> the release notes? >>> >>> We already have one for fixed-issues: >>> http://services.gradle.org/fixed-issues >>> >>> Used at: >>> https://github.com/gradle/gradle/blob/master/subprojects/docs/src/docs/release/content/script.js#L44 >> >> Cool. I had thought that the 'fixed issues' content was statically >> included. As it's dynamic, makes sense to have something very similar >> for known issues. > > This has been done. > > I've added a _new_ field to JIRA to capture whether an issue is a known > issue. I decided against using 'Affects Version' as that is slightly > different. > > Affects Version: The version(s) that the issue has been verified against. > Doesn't mean it was the first version to have the issue, but it is known to > have it > Known Issue Of Version: The version that this issue that _introduced_ > something that this issue is a defect/problem of > > Looking back at how we have historically used “known issue”, it's clear that > this is actually what we mean by it. Namely, that something that was > introduced/changed in this version is faulty. > > Options: > > 1. Go with what I have set up > 2. Use “Affects Version” as the data point and lose the ability to record > which versions are verified to exhibit the behaviour relevant to the issue > 3. Use “Affects Version” as the data point and introduce a new field to > record which versions are verified to exhibit the behaviour relevant to the > issue > > My vote is for #1.
This is a good option. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
