have I got this straight??

[philmoz]

when setting up a release (if set up properly), you don't actually have to upload the finished package.. the system can??/will?? generate the compressed package??

Or am I reading the instructions a tad wrong..

If this is right, what about all the files that have been uploaded previously? why are they then not accessible to the system, requiring the upload of individual files for the release... or am I missing something veeeery important?

[Boomzilla]

The file release system is organized in a hierarchical structure of packages, releases, and files. A package is a folder into which you can publish multiple related releases. A release is a group of one or more files that are published as a unit.

Each release can also have a maturity level attribute to describe its state of maturity. Maturity levels are predefined and include development build, alpha, beta, and general availability.

SourceForge does not generate compressed files for you -- you do that yourself based on the format you want (tar, zip, whatever) and then upload your file into the release within the  package you have already defined. (take a look at the Joomla! projec to see how they do it).

Col

[philmoz]

SourceForge does not generate compressed files for you -- you do that yourself based on the format you want (tar, zip, whatever) and then upload your file into the release within the  package you have already defined.

ok, doesn't produce compressed files, but does produce compressed package containing the files released... yes??

[philmoz]

ok, doesn't produce compressed files, but does produce compressed package containing the files released... yes??

answer, yes, page 200 of pdf manual...

The file release system is organized in a hierarchical structure of packages, releases, and files. A package is a folder into which you can publish multiple related releases. A release is a group of one or more files that are published as a unit.

ok, so looking at joomla project, package for all joomla 1.0.x, in which they place all joomla 1.0.x related releases from maintenance releases, to upgrade patches etc.(ok, gotcha)
.... someone has to actually upload the release file, be it a doc, text file, xml, zip, tar,tar.gz, html, php etc.

so, where is the relationship between the source / svn, and the final product.

Which is what I was driving at (poorly) in original post.

Is there a SF-software path that allows release from source, once it is agreed that it is complete, into the pre-prepared package as a release?

that is, project==>source repository==>[color=green]package==>release[/color]==> lots of downloads (ok, I can dream)

If there is, please point me to the manual page...

[edit]
as I currently understand it,  project==>source repository==>some nominated persons computer==|
then  project==>package==>[color=blue]some nominated persons computer==>release[/color]==> lots of downloads

[Boomzilla]

Hmmm - good question. I don't believe that there is the relationship for which you are looking (althout it would be valuable). I believe that the only way you add the files is via the Add files to a release/edit files in a release process (page 203 of the PDF user guide).

I'll ask folks who know more about this than I to post their comments.

Col

[mcjamison]

so, where is the relationship between the source / svn, and the final product.

Which is what I was driving at (poorly) in original post.

Is there a SF-software path that allows release from source, once it is agreed that it is complete, into the pre-prepared package as a release?

that is, project==>source repository==>[color=green]package==>release[/color]==> lots of downloads (ok, I can dream)

If there is, please point me to the manual page...

[edit]
as I currently understand it,  project==>source repository==>some nominated persons computer==|
then  project==>package==>[color=blue]some nominated persons computer==>release[/color]==> lots of downloads

Yep, your understanding is correct; there is no built-in mechanism to publish straight from repository to file release.  It's an interesting idea - though it would require a fairly complicated UI (picking  the subset of the repository's files to export, the branch or tag to check out from,  archive file type and name, etc.) and would only be useful for source-only releases. 

Fortunately,  the Soap API  makes this process eminently scriptable.  For our own internal development, we've built it into our own "continuous integration" automated testing setup.  After a snapshot passes our complete battery of tests on a given platform, that build is automatically uploaded to a file release - so we can go to one place on SourceForge to get the very latest builds that have passed tests on each platform. 

Cheers,
  -- Jamie

[philmoz]

thx Col and Jamie.

I won't lose any more sleep trying to find it 

now, to get the zipping issue sorted out...

[micheas]

Here is a link that describes how one group releases software with sourceforge.

http://docutils.sourceforge.net/docs/dev/release.html

It may help inspire someone to do this for our souceforge. Or at least gives a methodology for releasing software on sourceforge that seems to work.

[Boomzilla]

Indeed. There SourceForge has a SOAP API - one could write a small app that allows you to point at one or more files, and have the app grab them, zip them together and put them in the file release system.

If any one is interested in doing this we're planning to run a one-hour webinar in the next couple of weeks about the SOAP API and the programming model behind it. If you are intersted please PM me.

Col