Marshall Schor wrote: > Michael Baessler wrote: >> Michael Baessler wrote: >> >>> Fine with me to split up the Sandbox release into three releases. >>> >>> But I'm also fine with providing one release notes file that contains >>> all fixes, since we only have one Sandbox release with three artifacts. >>> >>> -- Michael >>> >>> >>> Marshall Schor wrote: >>> >>>> The mechanism in Jira to generate release notes is to select them by >>>> "release-name". We currently have 3 release names for 2.2.2: >>>> >>>> 2.2.2 >>>> 2.2.2S (for the sandbox) >>>> 2.2C (for C++) >>>> >>>> How shall we manage the 2.2.2 release: >>>> >>>> 1) use these 3 release #s >>>> 2) split the sandbox, adding 2.2.2AS (for uima-as), 2.2.2CE (for the >>>> Cas >>>> Editor), 2.2.2AN (for annotators + simple server) >>>> >>>> Or something else? >>>> >>>> (Note: it appears possible to assign an issue to more than one "Fix >>>> version"). >>>> >>>> Currently, the UIMA-AS has a uima-as-distr project, which has >>>> RELEASE_NOTES file which is supposed to contain the UIMA-AS >>>> issues. It >>>> seems a good idea to me to have these issues separated. I don't have a >>>> strong feeling for the other things. >>>> >>>> Right now, though, I'm stuck on building uima-as release candidate, >>>> because I don't have a reasonable way to generate the release notes. >>>> Anyone object if I create a new "release": 2.2.2AS, and reassign 2.2.2S >>>> issues that are also Async Scaleout component issues to that release? >>>> >>>> -Marshall >>>> >>>> >>>> >> Do do we proceed on this? Split up or go with once? >> If you want to split up the release notes I try to do this tomorrow. >> Note that there will be a lot of changes also for the issues we have, >> since they will all change there release version! We could try to make >> is as bulk processing without any notification. >> > I think it would be better for our users to split the release notes a > bit, using criteria: > - things where the user might want to separately upgrade or not > - things that might be released in the future on separate schedules > My suggestion: > 2.2.2 - base UIMA (exists) > 2.2.2as - uima-as > 2.2.2ss - simple server > 2.2.2an - annotators > 2.2.2ce - cas editor > 2.2.2C - c++ (exists) > > This might be too much to do for this release, though, so we may want to > do this over the next 2 releases. Each one of these probably would a > top-level project plus a xxx-distr project to hold the release-notes, > build info, etc. We have this already for > > base UIMA, uima-as, annotators+simple server, cas editor, and c++, I think. > > So - for this release, my vote would be to just split out changes for > uima-as and the cas editor. > The change should not be too hard to do with "bulk" - you could find > issues by components affected, where the release is 2.2.2S, and change > the 2.2.2S to the appropriate new suffix. I haven't done this before, > so this might not work ;-) > > -Marshall > I created additionally the releases 2.2.2AS and 2.2.2CE and added all issues for these components to these releases (changed from 2.2.2S to 2.2.2AS or 2.2.2CE)
So I think we split up the release notes into three sections. UIMA-AS -> 2.2.2AS CasEditor -> 2.2.2CE AnnotatorPacakge -> 2.2.2S Most of them where changed without notifications, some of them must be changed manually. Please update the release notes accordingly! Other comments, issues? -- Michael
