I've become tired of all the clicking it takes on berlios.de to delete old versions and set up new versions (and besides, I want it all to happen automatically, so I just start a script and it builds the autopackage, the tarball, the source dist, copies them to the FTP server, uploads to berlios and makes the new release on berlios).
To this end, I'm making a script that will click all the right buttons on berlios.de to make the old files disappear and the new files appear whenever a release is made. I'm trying to write it in such a way that it won't be specific to oolite-linux (or even oolite) - I'm hoping that the Windows maintainers can use it too to take the drudgery out of getting a new release on berlios.
I hope to have it done by the end of the weekend (I was hoping to do it all tonight, but berlios's site is a pain to script). It is written in perl and uses LWP (libwww-perl) and a bunch of the Perl http libraries to do its magic. I recommend ActiveState Perl for Windows. Most of it will be encapsulated in the 'UpdateBerlios' module, so if your procedures differ from what I do then it will be trivial to make a front end script for Windows even with very limited perl knowledge.
Maintaining the berlios site
Moderators: winston, another_commander
-
dajt
- Quite Grand Sub-Admiral
- Posts: 364
- Joined: Tue Aug 17, 2004 7:05 am
- Location: Orange, NSW, Australia
Re: Maintaining the berlios site
I learned all about this yesterday... took forever to get some old files hidden!winston wrote:I've become tired of all the clicking it takes on berlios.de to delete old versions and set up new versions
Your idea sounds good.
At some point I'd like you to explain your process, naming conventions, etc, because the Windows port should be able to follow the same conventions now.
Regards,
David Taylor.
David Taylor.
-
winston
- Pirate
- Posts: 731
- Joined: Mon Sep 27, 2004 10:21 pm
- Location: Port St. Mary, Isle of Man
- Contact:
OK, this is how it works mainly.
I keep these releases:
oolite-dev-source
oolite-dev-installer
oolite-stable-source
oolite-stable-installer
oolite-stable-binary-tarball
(The last one is really redundant, but I wanted to deprecate the tarball a bit in favour of the autopackage, but it seems like the tarball is still more popular).
Inside the 'dev' areas, I just have a 'dev' release - it's just too much of a pain in the arse to change the version number frequenty and hide all releases, so I didn't want to do it. Stable ones come along infrequently enough that it's not really an issue there.
Usually (but not always) when Giles does a Mac development release, I do one too (sometimes I put one inbetween Giles's if significant Linux stuff has hapened). The stable releases now happen in sync with the OS X stable releases (although there may be additional bug fix releases).
The naming scheme for the files is as follows:
Oolite-Operatingsystem-Ooliteversion-CPU
so Oolite-Linux-1.64-dev1-x86.tar.gz. Autopackage is Linux only so it drops the 'Linux' bit. However, the script that makes the tarballs should work on all Unix platforms, so it derives most of its filename from commands like 'uname'.
Stable releases are the same, except it's version-bugfixlevel - for example, 1.62-4. (If you look in svn you'll note there is a 1.62 branch. I backport worthwhile bugfixes, such as the AI fix or the screen shot bug into the 1.62 branch, then release a new stable version by incrementing the bugfixlevel number). The rule is only bug fixes go into those builds.
The script that does things like nightly builds (these are not released to berlios, just made available by rsync) and make the tarball installer (which is released to berlios) work out what the filenames should be and which dependencies to package. My current intention is to run all official builds off vexed3.alioth.net rather than my home machine so I'm not waiting an hour for it to go up my pathetic 256k upstream (vexed3 has 10Mbit upstream). What I hope to do for a proper dev release or stable release is just run one script on vexed3 which does the following:
- build the binary tarball installer
- build the Autopackage
- copy the appropriate files to the rsync destination
- copy the appropriate files to the FTP site
(these are already scripted, and since vexed3 is also the ftp site, it's just a matter of moving the build results to a different place on the disk).
- ftp files to berlios
- release files on berlios
The bits I'm doing next is the script to ftp this all up to berlios, delete the old files and add the new files, set the operating system and file type and all that damned clicking I have to do by hand right now. BerliOS is great in so much as it gives access to a decent bandwidth provisioned svn server, and a reasonable admin interface for news, adding users to the project etc. but the file release system utterly sucks from a user interface point of view, and if it can be automated all the better! My script already can log in, delete old files and select the new ones from the list. It needs to be able to determine the right settings to set for the architecture etc. and set them. One difficulty is that the berlios HTML doesn't seem to get parsed all that well for forms (some form elements dont' show up in the final parse tree). It goes without saying, it'd probably work much better if it was all XHTML 1.1! (My work projects are all valid XHTML 1.1 - it makes it SO MUCH easier to debug problems in what's spat out to the browser).
I'm also tempted to drop the tarball installer for Linux, it's not really needed (although it needs to be kept for Unices that don't yet have autopackage). I'm pretty certain I'll get rid of the 'binary-tarball' release even if I keep the binary tarball itself (so stable and dev are consistent).
I keep these releases:
oolite-dev-source
oolite-dev-installer
oolite-stable-source
oolite-stable-installer
oolite-stable-binary-tarball
(The last one is really redundant, but I wanted to deprecate the tarball a bit in favour of the autopackage, but it seems like the tarball is still more popular).
Inside the 'dev' areas, I just have a 'dev' release - it's just too much of a pain in the arse to change the version number frequenty and hide all releases, so I didn't want to do it. Stable ones come along infrequently enough that it's not really an issue there.
Usually (but not always) when Giles does a Mac development release, I do one too (sometimes I put one inbetween Giles's if significant Linux stuff has hapened). The stable releases now happen in sync with the OS X stable releases (although there may be additional bug fix releases).
The naming scheme for the files is as follows:
Oolite-Operatingsystem-Ooliteversion-CPU
so Oolite-Linux-1.64-dev1-x86.tar.gz. Autopackage is Linux only so it drops the 'Linux' bit. However, the script that makes the tarballs should work on all Unix platforms, so it derives most of its filename from commands like 'uname'.
Stable releases are the same, except it's version-bugfixlevel - for example, 1.62-4. (If you look in svn you'll note there is a 1.62 branch. I backport worthwhile bugfixes, such as the AI fix or the screen shot bug into the 1.62 branch, then release a new stable version by incrementing the bugfixlevel number). The rule is only bug fixes go into those builds.
The script that does things like nightly builds (these are not released to berlios, just made available by rsync) and make the tarball installer (which is released to berlios) work out what the filenames should be and which dependencies to package. My current intention is to run all official builds off vexed3.alioth.net rather than my home machine so I'm not waiting an hour for it to go up my pathetic 256k upstream (vexed3 has 10Mbit upstream). What I hope to do for a proper dev release or stable release is just run one script on vexed3 which does the following:
- build the binary tarball installer
- build the Autopackage
- copy the appropriate files to the rsync destination
- copy the appropriate files to the FTP site
(these are already scripted, and since vexed3 is also the ftp site, it's just a matter of moving the build results to a different place on the disk).
- ftp files to berlios
- release files on berlios
The bits I'm doing next is the script to ftp this all up to berlios, delete the old files and add the new files, set the operating system and file type and all that damned clicking I have to do by hand right now. BerliOS is great in so much as it gives access to a decent bandwidth provisioned svn server, and a reasonable admin interface for news, adding users to the project etc. but the file release system utterly sucks from a user interface point of view, and if it can be automated all the better! My script already can log in, delete old files and select the new ones from the list. It needs to be able to determine the right settings to set for the architecture etc. and set them. One difficulty is that the berlios HTML doesn't seem to get parsed all that well for forms (some form elements dont' show up in the final parse tree). It goes without saying, it'd probably work much better if it was all XHTML 1.1! (My work projects are all valid XHTML 1.1 - it makes it SO MUCH easier to debug problems in what's spat out to the browser).
I'm also tempted to drop the tarball installer for Linux, it's not really needed (although it needs to be kept for Unices that don't yet have autopackage). I'm pretty certain I'll get rid of the 'binary-tarball' release even if I keep the binary tarball itself (so stable and dev are consistent).