X. Check for empty directories and add stub files as necessary
(use preserve-empty-dir)
- 5. Commit your changes, and tag as v1.2.3-scripts1
+ 5. Commit your changes, and tag as v1.2.3-scripts
6. Run the "dry-run script", which uses Git commands to check how many
working copies apply the change cleanly, and writes out a logfile
8. Run the "deploy" script, which applies the update to all working
copies possible, and sends mail to users to whom the working copy
- did not apply cleanly.
+ did not apply cleanly. (It also frobs .scripts/version)
Note: The last three scripts will need to be implemented, with an
eye towards speed.
+* How to migrate an old autoinstaller to the new autoinstaller
+
+ - Find the oldest tarball/patch set for the application that still
+ is in use and upgradable.
+
+ - Untar, apply patch, place in a directory and git init
+
+ - Create the .scripts directory and populate it with the interesting
+ information (see below)
+
* The repository for a given application will contain the following files:
- The actual application's files, as from the official tarball
be in any language.
* .scripts/version which contains the version last autoinstalled
- (as distinct from the actual version the script is)
+ (as distinct from the actual version the script is) (This will
+ be auto-generated and should not be versioned)
* .scripts/real-version (+x) which checks the source code to find the
actual version of the application
5. git reset
+ 6. Setup .scripts/version (probably pipe the output of real-version)
+
* We will not add special code to handle .htaccess; thus the kernel patch
for allowing Apache access to .htaccess sent to scripts-team@mit.edu
must be handled first.
git pull /mit/scripts/deploy/wordpress.git master
if [ $? ne 0 ]; then git reset --hard; echo 'conflicts during upgrade'; fi
./.scripts/update
+
+* Make install-statistics generate nice pretty graphs of installs by date
+ (more histograms, will need to check actual .scripts-version files.)