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. > 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. > 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? -Adam
