Hi Marshall,

as usual, my view is pretty much the exact opposite ;-)

First of all, I don't see the sense in creating yet another
category.  To my mind, there's nothing wrong with having
mature components in the sandbox.  The only thing I would
consider is to move some sandbox components that are really
important to people into the core.

Also, at least while we're still in the incubator, I really
don't think individual releases for sandbox components are
manageable (unless I hear people volunteer to be release
managers for these things).

Also from a user perspective, I prefer a single download
with everything in it.  When I look at a new software and
go through the tutorial, I hate it when I have to get
components A, B, and C to do the first chapter, and then
for the next one, I need to get D and E, and so on.  A
couple of megabytes of download is insignificant these
days, and then you have everything on disc and can pick
and choose what you need.

Just my 2 cents.  If people are willing to do the work and
think that our users are better served by individual
downloads, that's fine with me, too.  Personally, I'll
defer to whatever the release manager for the sandbox,
whoever that may be, has to say on this subject :-)

--Thilo

Marshall Schor wrote:
> How do other projects do this kind of thing?
> 
> I'm thinking of the Commons project (was Jakarta Commons) - has lots of
> downloadable subparts; each is separate.
> 
> I don't have a strong preference, but I would lean toward the following
> kinds of things:
> 
> 1) having a new category of things:  Apache UIMA Components & Tools
> 
> 2) moving things we think are ready for release from the sandbox to this
> new category.
> 
> If things are really not ready for off-the-shelf kinds of users to use,
> I guess I would favor keeping those things in the Sandbox
> 
> On the question of "bundling" components versus making them available
> separately - I think in our case, the components that we have - it feels
> more like they would be better consumed as separately available things. 
> 
> At some point in the future, it may make sense to offer the whole set as
> a "package" - but I guess that seems less useful than having them
> separately available.
> 
> It also seems to me that these components would be on independent
> release cycles. 
> 
> -Marshall
> 
> Michael Baessler wrote:
>> Hi,
>>
>> I think now it is time to discuss how we should proceed with the
>> Sandbox components and how we will release them.
>> The Sandbox is a place to develop components or tooling and to play
>> with new technologies around UIMA. If some of the components are
>> stable and tested they
>> should be included to a Sandbox release. A Sandbox release has the
>> advantage the users know what are the reliable components and what are
>> the
>> components that are currently under development. I would like to
>> release the selected Sandbox components as bundle with each Apache
>> UIMA release under - "Apache UIMA Add-ons".
>> So the version number is the same for both releases and the effort is
>> minimized.
>>
>> Advantages:
>> - release effort is minimized since only one release for all
>> components must be done
>> - you can download only one package that contains all the components
>> and tools
>>
>> Disadvantages:
>> - the release number for a Sandbox component changes for each Apache
>> UIMA release independent of component changes
>> - the Sandbox components can not be downloaded separately which is
>> maybe an issue (??) for some companies
>>
>> To do the release building I'm going to create a new Sandbox project
>> called "SandboxDistr" which contains all the information to build and
>> package the components.
>> For analysis engine components I have created a PEAR packager maven
>> plugin (plugin will also be added to the Sandbox) that will be used to
>> create a PEAR package automatically
>> during the build. My plan was to ship the PEAR package additionally in
>> the binary distribution for a component.
>>
>> What do others think about this release approach?
>> Suggestions or comments?
>>
>> -- Michael
>>
>>

Reply via email to