Next release

[Thilo Goetz <tw...@gmx.de>]

All,

I think it's time we started thinking about the next
release.  We haven't had a release in a year, and while
there haven't been any major changes, we have fixed a
whole host of bugs, and we have acquired new items in
the sandbox.  Also there has been major progress in
UIMA-AS, which needs a new release.

I'll volunteer to be the release manager for this
release, but if anybody else would like to try their
hand, I'd be more than happy to forgo the honor.

Here are some things we should think about for the
next release, in no particular order.

* Getting releases approved by the incubator PMC is
intensely painful.  I therefore suggest, if we can,
to release everything at the same time, so we have to
go through the process only once.  By everything I mean
the Java core, UIMA-AS, and whatever of the sandbox
we want to release.  I'm not sure anything has happened
in C++ land since the first release, but we might want
to do a release anyway to get the version numbers
aligned.

* We have had some earlier discussions about changing
our release packaging a bit.  This concerns the sandbox
in particular, as there are things in there that are
quite stable enough to graduate from there to a place
still to be created.  This needs to be discussed, I don't
have a concrete proposal.

* If we have the time and the volunteers, we should
take a look at our Eclipse based tooling.  Can we add
the CAS Editor to our standard tooling?  Can we incorporate
code/ideas from the CAS Viewer as we had planned some
time ago?  What version of Eclipse do we still want to
support, i.e., can we prereq 3.4?  I might be able to
help with the tooling, but I'm afraid of breaking things
for older versions of Eclipse as I only took up Eclipse
programming recently.

* The version number: we could go with 2.3, or 2.2.3.
Arguments could be found for each, I don't have a strong
opinion.

Time frame (straw man proposal):

6/15 end of coding, only bug fixes after this point
6/22 end of testing, create distribution and submit for
     release vote
6/30 release

I'll be incommunicado for two weeks starting this Friday,
but I wanted to kick this discussion of before I left.  I
do think it's high time we did a release.  Please let me
know what you think (and if you'd rather be the RM ;-).

--Thilo

Re: Next release

[Thilo Goetz <tw...@gmx.de>]

Jukka Zitting wrote:
> Hi,
> 
> On Tue, May 12, 2009 at 5:56 PM, Thilo Goetz <tw...@gmx.de> wrote:
>> * Getting releases approved by the incubator PMC is
>> intensely painful.
> 
> I should be able to help with that.

That would be great :-)

> 
>> * The version number: we could go with 2.3, or 2.2.3.
>> Arguments could be found for each, I don't have a strong
>> opinion.
> 
> The number of improvements and new features tagged in Jira for the
> next release suggest that it should be called 2.3, though I'm not too
> familiar with your version numbering strategy.

Yes, I tend towards 2.3 as well, particularly if we change
the packaging around.

> 
>> Time frame (straw man proposal):
>>
>> 6/15 end of coding, only bug fixes after this point
>> 6/22 end of testing, create distribution and submit for
>>     release vote
>> 6/30 release
> 
> An alternative would be to create a release branch on 6/15 and
> selectively merge only bug fixes from trunk after that. This approach
> has the benefit that it allows normal development to continue in trunk
> while the release is being prepared. Not sure if it's worth the extra
> trouble though.

We're usually all busy getting the release out at a time
like that, so nobody is missing a dev stream.  If anybody
is, we can always branch.

> 
> BR,
> 
> Jukka Zitting

Re: Next release

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, May 12, 2009 at 5:56 PM, Thilo Goetz <tw...@gmx.de> wrote:
> * Getting releases approved by the incubator PMC is
> intensely painful.

I should be able to help with that.

> * The version number: we could go with 2.3, or 2.2.3.
> Arguments could be found for each, I don't have a strong
> opinion.

The number of improvements and new features tagged in Jira for the
next release suggest that it should be called 2.3, though I'm not too
familiar with your version numbering strategy.

> Time frame (straw man proposal):
>
> 6/15 end of coding, only bug fixes after this point
> 6/22 end of testing, create distribution and submit for
>     release vote
> 6/30 release

An alternative would be to create a release branch on 6/15 and
selectively merge only bug fixes from trunk after that. This approach
has the benefit that it allows normal development to continue in trunk
while the release is being prepared. Not sure if it's worth the extra
trouble though.

BR,

Jukka Zitting

Re: Next release

[Marshall Schor <ms...@schor.com>]

My opinions -

I prefer the release be numbered 2.3 to better reflect the extent of the
changes.  UIMA-AS in particular has had many changes.

I would like to promote some things out of the sandbox:  UIMA-AS, the
CAS Editor, and the stable annotators.

I would prefer the release to contain at least the above promoted
things, as well as of course the changes to base UIMA.

I would love to get a few of the easier-to-do space improvements to core
uima done, and included.  One candidate would be the one to change the
initialization of UIMA to not pre-load classes that may never be needed,
thus reducing the footprint of loaded classes, at least.

I hope someone has time to go through the open Jira's and give their
opinions about significant issues that should be fixed in this release.

-Marshall


Thilo Goetz wrote:
> All,
>
> I think it's time we started thinking about the next
> release.  We haven't had a release in a year, and while
> there haven't been any major changes, we have fixed a
> whole host of bugs, and we have acquired new items in
> the sandbox.  Also there has been major progress in
> UIMA-AS, which needs a new release.
>
> I'll volunteer to be the release manager for this
> release, but if anybody else would like to try their
> hand, I'd be more than happy to forgo the honor.
>
> Here are some things we should think about for the
> next release, in no particular order.
>
> * Getting releases approved by the incubator PMC is
> intensely painful.  I therefore suggest, if we can,
> to release everything at the same time, so we have to
> go through the process only once.  By everything I mean
> the Java core, UIMA-AS, and whatever of the sandbox
> we want to release.  I'm not sure anything has happened
> in C++ land since the first release, but we might want
> to do a release anyway to get the version numbers
> aligned.
>
> * We have had some earlier discussions about changing
> our release packaging a bit.  This concerns the sandbox
> in particular, as there are things in there that are
> quite stable enough to graduate from there to a place
> still to be created.  This needs to be discussed, I don't
> have a concrete proposal.
>
> * If we have the time and the volunteers, we should
> take a look at our Eclipse based tooling.  Can we add
> the CAS Editor to our standard tooling?  Can we incorporate
> code/ideas from the CAS Viewer as we had planned some
> time ago?  What version of Eclipse do we still want to
> support, i.e., can we prereq 3.4?  I might be able to
> help with the tooling, but I'm afraid of breaking things
> for older versions of Eclipse as I only took up Eclipse
> programming recently.
>
> * The version number: we could go with 2.3, or 2.2.3.
> Arguments could be found for each, I don't have a strong
> opinion.
>
> Time frame (straw man proposal):
>
> 6/15 end of coding, only bug fixes after this point
> 6/22 end of testing, create distribution and submit for
>      release vote
> 6/30 release
>
> I'll be incommunicado for two weeks starting this Friday,
> but I wanted to kick this discussion of before I left.  I
> do think it's high time we did a release.  Please let me
> know what you think (and if you'd rather be the RM ;-).
>
> --Thilo
>
>
>   

Re: Next release

[Thilo Goetz <tw...@gmx.de>]

Jörn Kottmann wrote:
>> * We have had some earlier discussions about changing
>> our release packaging a bit.  This concerns the sandbox
>> in particular, as there are things in there that are
>> quite stable enough to graduate from there to a place
>> still to be created.  This needs to be discussed, I don't
>> have a concrete proposal.
> 
> In my opinion we should remove the OpenNLP sample annotators,
> since we cannot ship OpenNLP with UIMA and the code
> is based on the outdated 1.3 version. Beside that will OpenNLP release
> a UIMA integration based on 1.4 in the near future.

+1  We should also point to OpenNLP from our
"external links" website.

> 
>> * If we have the time and the volunteers, we should
>> take a look at our Eclipse based tooling.  Can we add
>> the CAS Editor to our standard tooling?
> 
> I would love to see graduation of the Cas Editor. During the change
> to the eclipse plugin I also changed the build system to maven, which
> means that it is now build in the same way our other eclipse plugins are
> build.
> 
> To make the eclipse plugin also a tool which can be used during the
> development
> of the UIMA applications a user must add the cas editor nature to the
> project
> and configure all needed dependencies, like type system and styling.
> This could be eased through a "Add Cas Editor Nature" action like its
> done for PDE.
> 
>> Can we incorporate
>> code/ideas from the CAS Viewer as we had planned some
>> time ago?
> 
> Yes that would be cool, but I do not know the CAS Viewer well, so maybe
> Tong can point out a few things he wants in the Cas Editor, then I could
> work with him on integrating it.
> 
> Jörn

Re: Next release

[Jörn Kottmann <ko...@gmail.com>]

> * We have had some earlier discussions about changing
> our release packaging a bit.  This concerns the sandbox
> in particular, as there are things in there that are
> quite stable enough to graduate from there to a place
> still to be created.  This needs to be discussed, I don't
> have a concrete proposal.

In my opinion we should remove the OpenNLP sample annotators,
since we cannot ship OpenNLP with UIMA and the code
is based on the outdated 1.3 version. Beside that will OpenNLP release
a UIMA integration based on 1.4 in the near future.

> * If we have the time and the volunteers, we should
> take a look at our Eclipse based tooling.  Can we add
> the CAS Editor to our standard tooling?

I would love to see graduation of the Cas Editor. During the change
to the eclipse plugin I also changed the build system to maven, which
means that it is now build in the same way our other eclipse plugins are
build.

To make the eclipse plugin also a tool which can be used during the  
development
of the UIMA applications a user must add the cas editor nature to the  
project
and configure all needed dependencies, like type system and styling.
This could be eased through a "Add Cas Editor Nature" action like its  
done for PDE.

> Can we incorporate
> code/ideas from the CAS Viewer as we had planned some
> time ago?

Yes that would be cool, but I do not know the CAS Viewer well, so maybe
Tong can point out a few things he wants in the Cas Editor, then I could
work with him on integrating it.

Jörn