Adam Lally wrote:
> On Wed, Jul 2, 2008 at 3:06 PM, Marshall Schor <msa@schor.com> wrote:
>
>> We currently have the following "releases" done or being done or planned:
>>
>> 1 - main uima base (released 2.2.2-incubating)
>> 1a - main uima "hot fix" fp1 (out for a vote)
>> 2 - uima-as (it was not ready when the base was, and is just now out for a
>> vote) <note: this component has a 5D002 export classification>
>> 3 - uima - add-ons (annotators plus the simple server) (released,
>> 2.2.2-incubating)
>> 4 - cas editor (about to go out for a vote)
>> 5 - C++ (soon to go for a vote)
>>
>>
>
> Is it possible to have a single release (with a single version number)
> that could have multiple different binary packages (Java framework,
> C++ framework, async scaleout, tools, etc.), where all the parts get
> released and voted on at the same time? There could be just a single
> source distribution, and then various binaries. This might make
> things less fragmented and less confusing - for us, the IPMC, and our
> users.
>
Sure. It has the "pros" that you site. The "cons" are that it delays
other parts from being released until the all the parts are ready for
release. For instance, the C++ part isn't quite ready for release. I
do think that Eclipse is a good model - it has major releases, but the
other parts do have the ability to do other releases as well.
>
>> One thing I would like to see at some point going forward is not
>> up-versioning our Jars when they don't change from release to release. For
>> instance, when we release uima-base, it includes the jvinci jars - which
>> haven't been changed recently (I may be wrong here...), but it would be nice
>> to have that "stability" reflected in the release. I see that Eclipse often
>> does this in their releases.
>>
>>
>
> Do you mean not up-versioning the Maven artifacts? We don't have
> version numbers in the jar file names themselves (at least not yet).
> Maybe this fits with my suggestion above - a single release, but with
> the different jars (or other kinds of parts) marked with appropriate
> version numbers.
>
Right.
>> Likewise, it would be good to have the uima-as release, which is made to
>> "depend" on a particular base uima release, just include those jars (from
>> Maven, for instance) when creating the distributable "bin" artifact. (We
>> didn't do that for this last release because at the time we did the build
>> process, uima 2.2.2-incubating wasn't "out" yet).
>>
>>
>
> Hmmm... would you also do that for the C++ framework too, and the
> tools, etc.? Instead, how about an "everything" package that includes
> all the stuff?
>
I think this issue breaks down into the following considerations:
There are source and binary releases. The source ones have 2 purposes,
it seems:
(a) providing the new, additional sources that make up UIMA-AS
(b) providing something that users can "build" UIMA-AS from
These are not the same, because the current build process depends on
sources from the base. We did a compromise for the first release of
including some of the sources from the base needed for building. We
could and maybe should work on the build-from-source process to have it
be more modular, and try to make (b) work with (a) sources.
Also, if I understand you right, you're suggesting that we have just an
"everything" package, instead of these "add-on" packages. If we have
just an everything package, would we not have a base package? That
would mean that people who wanted just uima base would be downloading a
lot more than they will use.
We could, of course, have a style where the binaries would be:
base
base + annotators
base + annotators + simple server
base + uima-as
base + c++
etc., various "combinations" of the parts. I think such a packaging
would get out of hand (too many variants).
Or, perhaps you're suggesting:
base
base + everything else (or a subset of everything else - e.g.,
uima-as, cas editor, annotators, but not the simple server?)
I think our offerings will continue to grow, and may become more diverse
(e.g., a sample "Type System", or corpora for training, or repository
functionality might be added). So I lean toward a strategy that allows
for some number of "parts" as separately managed things, together with
an attempt to occasionally put out semi-synchronized "big" releases with
all or most of the parts, like the Eclipse approach.
-Marshall
|