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