uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Baessler <...@michael-baessler.de>
Subject Re: Release Upload
Date Thu, 20 Dec 2007 11:51:18 GMT
Michael Baessler wrote:
> Robert Burrell Donkin wrote:
>> On Dec 19, 2007 9:28 PM, Marshall Schor <msa@schor.com> wrote:
>>  
>>> Michael, can you upload?  I think a good candidate layout for uploading
>>> would be:
>>>
>>> ...dist/uima/KEYS   where the public keys go
>>>
>>> The httpd project has an organization of
>>>    binaries    /   release-id'd artifacts    << for binaries
>>>    docs        /   release-id'd artifacts   << for documentation
>>>    (nothing)  /  release-id'd artifacts      << for source, 
>>> announcements
>>>
>>> They also have at the top level, besides the KEYS dir,
>>>    Announcement-<release-version>
>>>    CHANGES-<release-version>
>>>     
>>
>> if you're going to stuff at the top level, a header.html can sometimes
>> be useful (see eg http://www.apache.org/dist/httpd/)
>>
>>  
>>>     libapreq    << a place to put libraries which are prereqs, I think,
>>> which don't change from release to release.
>>>    patches      << a place to put patches to releases
>>>    tools          << tools they use to create releases (this seems the
>>> wrong place to put such things, to me).
>>>
>>> An alternative would be to switch the order:
>>>    start with the release-id (e.g. uimaj-2.2.1-incubating)
>>>           and have under it:
>>>           bin
>>>           src
>>>           doc
>>>
>>> Any opinions as to preferences?  Robert - is there a "best practice" 
>>> here?
>>>     
>>
>> there are several reasonable starting points for developing a process
>> that works.
>>
>> you've already highlighted httpd which usually sets a standard.
>>
>> ant is another standard followed by many projects including commons.
>> see http://www.apache.org/dist/ant/ and
>> http://commons.apache.org/releases/mirror.html. the idea is that easy
>> symlinks are available from the top level.
>>
>> review a few strategies and then see what's likely to works best for 
>> UIMA
>>
>>  
>>> My slight preference is to have, for those things that occur with every
>>> release, the organization of
>>>    uimaj-2.2.1-incubating / bin
>>>    uimaj-2.2.1-incubating / src
>>>    uimaj-2.2.1-incubating / doc
>>>
>>> I think this will make "archiving the release as a unit, somewhat 
>>> easier.
>>>     
>>
>> archiving is done automatically (by a sync). all that matters is to
>> remember to delete old releases from dist (it's usually a release
>> manager task - when a new release is added, an older one is deleted.)
>>
>> - robert
>>   
> I would prefer an organization similar to ant or http like:
>
> binaries/uimaj-2.2.1-incubating/<artifacts>
> source/uimaj-2.2.1-incubating/<artifacts>
> docs/uimaj-2.2.1-incubating/<artifacts>
> KEYS/<keys file>
>
> with that layout the automatic archiving is structured as well. Since 
> we have the same layout.
> As far as I understand the automatic archiving.
>
> Do all agree with that layout?
>
> -- Michael
>
>
I added a preview of the upload to p.a.o/home/mbaessler/mirrorLayout

-- Michael

Mime
View raw message