Adam Lally wrote:
On Tue, Jul 8, 2008 at 12:21 PM, Marshall Schor <[EMAIL PROTECTED]> wrote:
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.
I was suggesting that an "everything" package might replace what you
were suggesting as the "base + uima-as" package. I haven't completely
made up my mind about dropping the base-only release. Would our users
really be that upset about getting extra stuff they don't want? (I
don't think we're talking about huge amounts of stuff to download, are
we?)
I agree that simpler is better, and bundling things is simpler. But
(there's always one of these... ) uima-as is quite a bit "bigger" than
the base; includes in its distribution the Spring framework, ActiveMQ,
and Saxon (the XSLT transformer), as well as the custom code for uima-as.
Furthermore, if we have a lot more tools under development, it may
make sense to consider tools separate from the "base" - and at that
point would anyone want a base-only release?
I agree it's simpler / better to have most of the tools in the base -
which is where we have them now, except for tools which are specific to
uima-as are packaged with uima-as (this is the extension to the
component descriptor editor to support editing deployment descriptors).
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.
I think having synchronized (why only semi?) "big" releases with all
the parts (at least all the mature ones) would be a big improvement.
Semi - meant that not all of the components might be in the big
release. For instance, if at some point we host test "corpora", those
might not change very much, and not be in the release.
As for the piecemeal releases, could these only be for minor version
updates since the last major release?
Yes, that was the idea. Also would be good to allow them as initial
releases. So, for instance, if we had 2.2.2 out, and finally the C++
version is approved for release, it could be at the 2.2.2 level, but
released separately. Following that, we could fold it into the the next
big release, if we were doing all of it together.
I can see some value in having
separate bug-fix updates for different components, sort of like the
hotfix we just had (but with changing the version #). The idea is
that users can avoid doing any update at all if the only thing that's
changed is something they don't use. So we're saving the user work,
rather than adding more work which is what we're doing by not having
any synchronization at all between our parts and forcing users to
download things piecemeal as they become available.
I agree.
Perhaps we should separate these 2 ideas:
(1) releasing: this is a process of packaging, voting, uploading, etc.
(2) packaging: (warning - I'm dreaming here) maybe we could invent some
new approach whereby the downloader could easily select exactly what
they wanted from our web site, from a single item to sets of items...
-Marshall
