Comments on: Automating Release Tasks

By: pmjones

pmjones — Fri, 14 Apr 2006 00:08:31 +0000

Hi Eric — yes, for about 30 seconds. Then my allergy to XML kicked in. ;-)

By: Eric Coleman

Eric Coleman — Thu, 13 Apr 2006 21:31:48 +0000

Did you consider using Phing?

By: Bien batido y revuelto » Ã‰sta va de PHP

Bien batido y revuelto » Ã‰sta va de PHP — Wed, 12 Apr 2006 16:13:48 +0000

[...] Seguimos con un proceso automatizado para generar releases del software escrito por el autor de (Â¡seguimos con los frameworks!) en el que explica como ha desarrollado un sistema para crear releases de su software de forma automÃ¡tica (algo mÃ¡s complejo que hacer un tar.gz ;-) ) [...]

By: pmjones

pmjones — Wed, 12 Apr 2006 02:47:06 +0000

Hi Rick –

That’s a good idea (re: run tests are part of the release script). Right now I just make sure they all run before I do the release. But it would be easy to add a a testing script that does the test-run and only generates output on failures, then it can hook it into the release process the same way “svn status” does. (I already have “all.php” to run all the tests, but it generates output.)

By: pmjones

pmjones — Wed, 12 Apr 2006 01:40:57 +0000

Hi Ivo — Good comments.

As far as release candidates are concerned, these are only alpha-stability releases, so I’m OK with lots of little releases. If I were already at “stable” you can bet I’d be making RCs instead.

As far as the upload, I’ve not taken the time to see how to push that up to the PEAR channel server yet; it’s a trivial task, so I’m not too concerned about it (yet).

By: Rick

Rick — Wed, 12 Apr 2006 01:33:22 +0000

Thanks for the notes. I have been going through the book “Practices of an Agile Developer” and was wondering how a system could auto-build php rather than compiling Java apps and such. Looks like I have some pear reading to do.

On a side note as I’ve also started doing tests, do you integrate the testing into the release process or just make sure they all go before initiating the new build?

By: pmjones

pmjones — Wed, 12 Apr 2006 00:36:31 +0000

Greg, you’re right, it does work as you say. I must have been doing something wrong in my earlier experiments with addGlobalReplacement(). I have updated the entry to reflect your advice; thanks. :-)

By: Greg Beaver

Greg Beaver — Tue, 11 Apr 2006 22:52:27 +0000

[quote]The PEAR_PackageFileManager has a great auto-replacement utility built in. It can look through the source code at installation time and replace certain keywords, such as â€œ@package_version@â€, with the proper value for that particular installation.

But thereâ€™s a small problem with that for non-PEAR users. Because the replacements happen at installation-time, not at package-time, it means… [/quote]

This is incorrect, for package-info and php-const replacements, all replacements happen at packaging time, but *only* for package.xml 2.0-based packages (which Solar is). Incidentally, this feature is internal to PEAR, PEAR_PackageFileManager simply uses it. If this isn’t happening, we have a problem.

By: Ivo Jansch

Ivo Jansch — Tue, 11 Apr 2006 21:32:46 +0000

That should’ve been “./release.sh tagname where tagname is the CVS tag…” but I had lt/gt’s around it which wordpress decided to strip :)

By: Ivo Jansch

Ivo Jansch — Tue, 11 Apr 2006 21:31:44 +0000

For ATK, I’ve automated all but writing the release notes. I just run ./release.sh where is the CVS tag I’ve put on the repository to mark the release. The upload is handled using scp.

If you are finding yourself releasing 5 releases in 7 days, you might want to consider working with release candidates (people that want stable releases can wait one or two rc’s before downloading the final release) and/or automated nightly builds that people can download.

Release candidates is useful if you find yourself often fixing bugs right after a release. It ensures more stability for ‘actual’ releases, and you can announce the rc’s to a smaller audience.

Nightly builds is useful if you commit a lot of features that users want sooner than the next stable release.