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
