You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Marshall Schor <ms...@schor.com> on 2008/03/25 18:40:25 UTC
Release notes
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
Re: Release notes
Posted by Marshall Schor <ms...@schor.com>.
Michael Baessler wrote:
> 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?
>
I found 13 issues marked with the component uima-as, which were
"resolved" or "closed", which had "empty" fix versions. These I added
the fix version = 2.2.2AS, as a bulk change.
-Marshall
Re: Release notes
Posted by Thilo Goetz <tw...@gmx.de>.
Michael Baessler wrote:
> 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
Just for the record, I think we need to rethink
our release naming policy after this release.
Creating a Jira issue becomes more and more painful.
How are users supposed to know which of the various
2.2.2XXX release they're supposed to select when
they open an issue?
--Thilo
Re: Release notes
Posted by Michael Baessler <mb...@michael-baessler.de>.
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
Re: Release notes
Posted by Marshall Schor <ms...@schor.com>.
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
Re: Release notes
Posted by Michael Baessler <mb...@michael-baessler.de>.
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
Re: Release notes
Posted by Michael Baessler <mb...@michael-baessler.de>.
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
>
>