Release Process

[ Start > PikeDevel > Release Process ] [ Edit this Page | Show Page Versions | Show Raw Source ]


Yep. It goes something like this:

1. The current release manager thinks it's been to long since the last release.

1. The release manager asks for outstanding issues¹ including an up to date CHANGES.

1. Outstanding issues are fixed and someone will check in new features in panic² to get them in the new release. Repeat 2.

1. If the release manager did not time out in the above loop a beta is done. Repeat 2.

1. If the release manager did not time out in the above loop a release is done.

The bundles are just library distributions. Patches against them are applied during the client make process, if the destination host has no suitable library. I don't know if it is possible to force the bundles to be used, which might be desired.

Note that the libs put into the dist bundle should be the same as in the Xenofarm dists, otherwise we'll probably have a problem. More importantly, we don't know if we have a problem or not :)

If we assume that the loop outlined by Peter Bortas is done, (all "musts" have been backported, Unicode is updated etc. and the CHANGELOG is done) then the following should occur.

The source should of course build with Xenofarm and active measures should be take to have it green on as many systems as possible. Often problems are with the machines, so this usually involves quite a bit of sysadm work.

I always make a few manual tests with the source such as make verify on a dmalloc build and a make verify within valgrind.

Checks for some previous mistakes has been added to the tools/release_checks.pike, and should be run.

Bundles should be added to the bundles directory.

git clone git-pike@pike-git.lysator.liu.se:pike.git pike-git
cd pike-git
cp ../pike-pelix/bundles/*.gz bundles/
git checkout -b 7.8 origin/7.8
CC=gcc-4.2 CFLAGS="-m32 -march=i686" make CONFIGUREARGS="--with-abi=32 --without-machine-code"
make release_checks
make doc
make export

The exported build must then be tested on another computer so that it build and then a binary dist should be made (make bin_export).

The exported binary build must then be tested on yet another computer so that it installs. I guess that the external module build system with monger should be tested here as well.

Weehee! The build is good! You rarely get down all the way here without cheating and forgetting a test or two :) Now release the source and make proper binary builds on various platforms.

Start working on windows binary....

¹ Room for optimizations: Someone could take it upon him or her to keep an updated list of issues, separated in classes like "securty", "regressions" and "bugs". Preferably in Crunch.

² Room for optimizations: Getting releases out more often always makes this step less troublesome.


Powered by PikeWiki2

 
gotpike.org | Copyright © 2004 - 2009 | Pike is a trademark of Department of Computer and Information Science, Linköping University