setting up for download of release

[Marshall Schor <ms...@schor.com>]

I looked at several incubator projects to see how they're doing things.

Most have a downloads html page on their website (so do we - for 
downloading the Eclipse Code Style Prefs).

Where they host the download zip / tar file varies, including:
   people.apache.org/some-user 
   the project website, under a dir called "downloads"
   The maven repository for incubating projects: 
      people.apache.org/repo/m2-incubating-repository/
          
org/apache/openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6-incubating-binary.zip

I don't know the reason for the repeated names in this example - they 
seem redundant to me.

Have we discussed how to do this?  My preference would be to borrow 
something like OpenJPA does
(incubator.apache.org/openjpa/downloads.html) and change it to suit.  I 
don't have a strong
feeling about using Maven repository - I think that may be useful if 
other projects are treating your project
as a maven component - and I don't think we've crossed that bridge yet, 
so something simpler would probably
be better for now?   My (slight) preference would be to have our 
downloads in our existing /downloads directory.

I suppose we need a "temporary place" to put these before they are 
officially blessed.  Maybe we could set up a dir called
to_be_approved, with subdirs /downloads and /download.html - this latter 
being a proposed update to our existing
download page.  Other opinions?

-Marshall

Re: setting up for download of release

[Adam Lally <al...@alum.rpi.edu>]

On 2/12/07, Marshall Schor <ms...@schor.com> wrote:
> I looked at several incubator projects to see how they're doing things.
>
> Most have a downloads html page on their website (so do we - for
> downloading the Eclipse Code Style Prefs).
>
We have a downloads.html page which is just a placeholder for links to
our releases.  It doesn't have the Eclipse Code Style Prefs.  (I did
put the Eclipse Code Style Prefs in a directory called "downloads",
but that was just because I needed to put it someplace that wasn't
just alongside all the other .xml source files for our website.)

> Where they host the download zip / tar file varies, including:
>    people.apache.org/some-user
>    the project website, under a dir called "downloads"
>    The maven repository for incubating projects:
>       people.apache.org/repo/m2-incubating-repository/
>
>

I see a lot of them hosted at http://people.apache.org/dist/incubator.
 Looks to me like that's the preferred place for those not using
Maven.

org/apache/openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6-incubating-binary.zip
>
> I don't know the reason for the repeated names in this example - they
> seem redundant to me.
>

You mean why is the directory 0.9.6-incubating needed?  I think it's
because that directory would contain many files - the binary and
source distributions, and their signatures/checksums.  I think that's
a good idea.

> Have we discussed how to do this?  My preference would be to borrow
> something like OpenJPA does
> (incubator.apache.org/openjpa/downloads.html) and change it to suit.  I
> don't have a strong
> feeling about using Maven repository - I think that may be useful if
> other projects are treating your project
> as a maven component - and I don't think we've crossed that bridge yet,
> so something simpler would probably
> be better for now?   My (slight) preference would be to have our
> downloads in our existing /downloads directory.
>

Can you give an example of another project that has their downloads in
their website's downloads directory?  OpenJPA doesn't seem to (it has
links to the maven repository).  Maybe it's discouraged?

I think we don't need to worry about putting our stuff in the Maven
repository, yet.  We can always do that later.

-Adam

Re: setting up for download of release

[Michael Baessler <mb...@michael-baessler.de>]

Marshall Schor wrote:
> I looked at several incubator projects to see how they're doing things.
>
> Most have a downloads html page on their website (so do we - for 
> downloading the Eclipse Code Style Prefs).
>
> Where they host the download zip / tar file varies, including:
>   people.apache.org/some-user   the project website, under a dir 
> called "downloads"
>   The maven repository for incubating projects:      
> people.apache.org/repo/m2-incubating-repository/
>          
> org/apache/openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6-incubating-binary.zip 
>
>
> I don't know the reason for the repeated names in this example - they 
> seem redundant to me.
>
> Have we discussed how to do this?  My preference would be to borrow 
> something like OpenJPA does
> (incubator.apache.org/openjpa/downloads.html) and change it to suit.  
> I don't have a strong
> feeling about using Maven repository - I think that may be useful if 
> other projects are treating your project
> as a maven component - and I don't think we've crossed that bridge 
> yet, so something simpler would probably
> be better for now?   My (slight) preference would be to have our 
> downloads in our existing /downloads directory.
>
> I suppose we need a "temporary place" to put these before they are 
> officially blessed.  Maybe we could set up a dir called
> to_be_approved, with subdirs /downloads and /download.html - this 
> latter being a proposed update to our existing
> download page.  Other opinions?
>
> -Marshall
>
>
+1

The simple way without using Maven sounds good to me.

-- Michael

Re: setting up for download of release

[Thilo Goetz <tw...@gmx.de>]

Thilo Goetz wrote:
...
> What I have seen done is that release managers put up the pre-approved 
> level on their private website on people.a.o.  I don't really care where 
> we put it, as long as we don't link to it from anywhere.  There's no 
> point in putting up artificial boundaries as the source code is freely 
> available, just so nobody other than incubator folks are tempted to look 
> for it.
> 
> --Thilo
> 

It's time to stop when you need to reply to your own mail.  When I said 
"pre-approved", I meant levels before they're approved as releases.  I 
guess that was probably clear from the context, it's just not what 
"pre-approved" usually means.

--Thilo

Re: setting up for download of release

[Thilo Goetz <tw...@gmx.de>]

Marshall Schor wrote:
> I looked at several incubator projects to see how they're doing things.
> 
> Most have a downloads html page on their website (so do we - for 
> downloading the Eclipse Code Style Prefs).
> 
> Where they host the download zip / tar file varies, including:
>   people.apache.org/some-user   the project website, under a dir called 
> "downloads"
>   The maven repository for incubating projects:      
> people.apache.org/repo/m2-incubating-repository/
>          
> org/apache/openjpa/openjpa-project/0.9.6-incubating/openjpa-project-0.9.6-incubating-binary.zip 
> 
> 
> I don't know the reason for the repeated names in this example - they 
> seem redundant to me.
> 
> Have we discussed how to do this?  My preference would be to borrow 
> something like OpenJPA does
> (incubator.apache.org/openjpa/downloads.html) and change it to suit.  I 

+1, if there is enough space on people.a.o (and there seems to be).

> don't have a strong
> feeling about using Maven repository - I think that may be useful if 
> other projects are treating your project
> as a maven component - and I don't think we've crossed that bridge yet, 
> so something simpler would probably
> be better for now?   My (slight) preference would be to have our 
> downloads in our existing /downloads directory.
> 
> I suppose we need a "temporary place" to put these before they are 
> officially blessed.  Maybe we could set up a dir called
> to_be_approved, with subdirs /downloads and /download.html - this latter 
> being a proposed update to our existing
> download page.  Other opinions?

What I have seen done is that release managers put up the pre-approved 
level on their private website on people.a.o.  I don't really care where 
we put it, as long as we don't link to it from anywhere.  There's no 
point in putting up artificial boundaries as the source code is freely 
available, just so nobody other than incubator folks are tempted to look 
for it.

--Thilo