You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by Michael Baessler <mb...@michael-baessler.de> on 2008/04/01 17:55:54 UTC
Re: Release notes
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 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