I suspect a lot of people are put off downloading and testing the TWikiAlphaRelease by the requirement to use CVS. I know I was before joining the CoreTeam, even though I had used CVS a bit before.

So, how about putting together ZIPs of the TWiki code, ideally on a nightly basis through a scheduled script, to make it easy to grab the latest code for testing? This would also fit into the Google:Cathedral+And+Bazaar model of 'release early, release often', by allowing many people, not just the core team, to easily download and test such releases.

This is of course complementary to the TWikiBetaRelease model where a more tested release is put together that includes the TWiki distribution topics as well.

What do you think?

-- RichardDonkin - 26 Apr 2002

I think this is a good idea. People would still have to register to get the last production or beta release as alpha would not include data and pub directories.

-- JohnTalintyre - 26 Apr 2002

I like it. I would like to contribute to testing, but want it simple. ZIP is for me much simpler to install than applying diffs.

-- PeterMasiar - 29 Apr 2002

I've been doing some work on nightly alpha release builds - these are now generated every night at 23:45 (Pacific time) as tar.gz and .zip files, and placed into http://twiki.org/alpha/. Give them a try!

I'm using http://cvsutils.sf.net to do the checkout and tar/zip builds, which helps quite a bit.

TO DO:

• Purge old alpha files on every run - done
• Table of alpha files using %ALPHAFILES% in default plugin - done by PeterThoeny
• Rename alpha files to be consistent with beta etc - done

-- RichardDonkin - 23 Nov 2002

Created %TWIKIALPHAFILES% in DefaultPlugin showing a table of all Alpha files currently available:

Cairo Alpha's from SVN

http://svn.twiki.org/users/alpha/pub/

-- PeterThoeny - 25 Nov 2002

Nice feature ... This approach could also be useful for people who want to have external processes creating directories of files that are then tabulated - provides more flexibility than attachments for this sort of thing, particularly where the directory already exists on some other intranet website... I can see quite a few applications for this!

cvsrelease likes the filename to be module-suffix, where module is the CVS module, i.e. twiki, but I have implemented a rename to the TWiki* format, see above.

-- RichardDonkin - 26 Nov 2002

The major thing stopping me from acively using the AlphaRelease for my testing is that the NonCorePlugins are not part of the cvs update, nor am i able to cvs update them from the Plugins CVS repository (if they were there.) as the nonCorePlugins filesystem overlaps with the TWiki one.

So... there are a number of things that would get me over this hump

1. get the plugins into the TWikiPluginsCVS (i am willing to add some)
2. change the way NonCorePlugins are found (by adding another config file parameter?) to allow side by side installation
3. I would like to see a TWikiDataCVS so the whole twiki package can be sourced from CVS

-- SvenDowideit - 28 Nov 2002

Presumably the non-core plugins don't change very often, so I don't quite see why this is stopping you from testing the alpha release. Of course, it may be less convenient to have to download separate plugin files and manually install them, and we should try to make it as easy as possible.

Re the overlapping file trees - you would normally have a twiki and a twikiplugins tree, both updated from CVS - then you just write a simple script to copy the plugins that you want into the target tree (e.g. /twiki, i.e. not into the twiki CVS tree). Doesn't seem very hard to me. Your suggestion 2 seems unnecessary given this approach.

Everyone seems to have different preferred ways of doing things - for most people, downloading ZIP files is easier than using CVS, hence the new alpha release ZIP files. Unless TWiki starts supporting TWikiOnCVS (unlikely for now), there would have to be a separate step to extract the files from the TWiki.org trees and put them into CVS. Since TWiki does its own RCS version control, it's not clear how useful a separate repository really is, though it might make some things easier.

-- RichardDonkin - 28 Nov 2002

Yeah I agree that its simple to get things to work, but I run my work wiki directly from a cvs checkout, and I have another checkout that I do coding and testing from. in paralell to this I have another checkout from twiki.org, but without the plugins that we use it's simpley less useful to me. Its quite funny to me how my way of working has changed since i moved from a company using VSS to one that uses cvs.

I only put in point 3 to show the direction that I'm leaning - its the way that I'm working with all the other open source projects that I use..

-- SvenDowideit - 28 Nov 2002

Apologies if this is the wrong place, but I'd love to see the %ALPHAFILES% implementation, as I need to do something similar on my intranet. I couldn't find it in CVS though, so I guess it's local to twiki.org

-- MichaelKearns - 03 Jan 2003

Here we go in regards to showing the files. In commonTagsHandler of the DefaultPlugin add this:

    $_[0] =~ s/%TWIKIALPHAFILES%/twikiAlphaFilesHandler( )/geo;

And add this new function:

# =========================
sub twikiAlphaFilesHandler
{
    my $alphaDir = TWiki::Func::getPubDir();
    $alphaDir =~ s|(/htdocs).*|$1/alpha|;
    opendir( DIR, "$alphaDir" ) or return "could not open $alphaDir";
    my @files = reverse sort grep /^TWiki.*zip/i, grep !/^\.\.?$/, readdir DIR;
    closedir DIR;
    my $text = "   | *Alpha Release Date* | *ZIP File* | *Tar.gz File* |\n";
    foreach my $file ( @files ) {
        my $date = $file;
        $file =~ /.*?([0-9]{4})[\-\.\/]*([0-9]{2})[\-\/]*([0-9]{2}).*/;
        $date = "$1/$2/$3";
        $text .= "   | $date | ";
        $text .= "[[http://TWiki.org/alpha/$file][$file]] |";
        $file =~ s/zip$/tar.gz/;
        $text .= "[[http://TWiki.org/alpha/$file][$file]]" if( -e "$alphaDir/$file" );
        $text .= " |\n";
    }
    return $text;
}

-- PeterThoeny - 04 Jan 2003

DEVELOP Branch Alpha's

• see http://develop.twiki.org/users/develop/pub/BuildDistros/