uima-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marshall Schor <...@schor.com>
Subject Re: Release Upload
Date Thu, 20 Dec 2007 17:19:27 GMT
As Robert has pointed out (several times, I think :-) )  we should not
take "archiving" issues into account in doing the layout.  This is
because whatever we upload into dist/incubator/uima, in whatever
directory layout, is rapidly copied, using that same directory layout,
to the archive place and remains there forever.

So - I think we should consider this decision, not from archiving ease
point of view, but rather from our users point of view, and our own
point of view.

It's up to us to decide when to "archive" (that is, delete from the
dist/incubator/uima) a particular release.  Many projects keep several
releases on the mirrors, especially if new downloaders would have a
particular reason to want to download a previous release.  In UIMA's
case, so far - I don't think we will have much traffic wanting to
download previous releases, but if we do a major change (like, for
instance, next year, we might want to be changing things to align with
the to-be-released UIMA Standard), then we might want to have 2 releases
on dist/incubator/uima.

>From the user's point of view, our download HTML page can make this
clear, and this would be quite independent of the actual layout in
dist/incubator/uima (henceforth, written as d/i/uima).  I do note that
some users might want to actually look at the d/i/uima "directory"
instead of looking at the download HTML page; so there's some value in
having an easy-to-understand organization there.

So - my preference would be mostly one of "don't care", but with a very
slight leaning toward having the release event result in the creation of
a new subdir under d/i/uima/<release-identification> and under that, the
set of files that go with that release; with files that don't change
with each release, like KEYS, at the top.  Such an organization would
allow a user browsing the directories to download both the binary and
source releases for a particular version, perhaps slightly more easily. 

I can also see the value of top level "binaries, source, docs"
organization, because a user browsing the directory would likely have in
mind one of these things they want to go after (although, that might run
into difficulties if we distribute things that don't fall into these
categories, at some point).

-Marshall

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
>
>
>
>


Mime
View raw message