This could even be an ant target in the top level build.xml file.

-David


On Oct 26, 2007, at 4:44 AM, Jacopo Cappellato wrote:

I agree with starting with a simple script to get a monthly source tarball; then we can get more feedback and possibly improve the strategy.

What are the next steps?
After reviewing the Apache Infrastructure guidelines (http:// apache.org/dev/release.html), it seems that the right location for svn snapshots for Apache projects is in people.apache.org/builds

Is there anyone here who can help to prepare a script to automate the process (svn export|tar ...|mv ...); where should the script reside?

Jacopo


Ray Barlow wrote:
+1 for the simple tar/zip download principle as a monthly head build and as David suggests it's needs a script of some sort to make it's creation
simple. Go with the KISS principle.
I'm not so sure on the SVN inclusion as I've had problems in the past
trying to transfer deployments across platforms i.e. copying a Windows based SVN checkout onto a Linux based OS or vice versa and then trying to use SVN commands like "svn up" invariably it would result in errors about SVN version incompatibilities. That's even when both platforms are
running recent distros with updates.
I would see this as the base for the debian and rpms deployments i.e. if
brainfood or others were up for it they could take the monthly simple
tar/zip package and repackage for apt etc.
Ray
Jonathon -- Improov wrote:
Having both will be good.

The SVN workspace download is for those who want to easily
upgrade/update in future. This is needed even by newbies who may need to conveniently pull in critical updates, esp if they're playing with
trunk.

The non-SVN download (generated by svn export) is for those who do not
intend to do any incremental updates in future. That means they'll
have to re-download a whole bunch for future versions.

Jonathon

Jacques Le Roux wrote:
Why not both ? They have different goals. We may recommend good open
source free tools. On Windows I would recommend 7-zip !

Jacques




Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to