Adam Lally wrote:
On Wed, Jul 2, 2008 at 3:06 PM, Marshall Schor <[EMAIL PROTECTED]> 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
