PikeDevel/Release Process

Release Process

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

Yep. It goes something like this.

The release manager thinks it's been too long since the last release.
The release manager asks for outstanding issuesš including an up to date CHANGES.
Outstanding issues are fixed and someone will check in new features in a panic˛ to get them in the new release. Repeat 2.
If the release manager did not time out in the above loop a beta is done. Repeat 2.
If the release manager did not time out in the above loop a release is done.

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 (no longer applies post 7.8).

COPYFILE_DISABLE=1 export COPYFILE_DISABLE

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....

The source tarball and any binary dists should be uploaded to pike.lysator.liu.se. Create a folder for the version within "beta" for non-final releases and "all" for official releases.

Update the website/ftp site:

- Symlink pub/pike/all/version to pub/pike/latest-stable

Log into sitebuilder
Update download/versions.json
From the changes page, use the on-site form to create a new changelog item (you can copy the "changes since" text from CHANGELOG into this new item and it will automatically format it for the website).
From sitebuilder, add the new changelog item to download/notes/index.xml
From the news page, Create a new news item using the on-site form. You will then need to edit that news item xml page in sitebuilder to add HTML content with the download and changelog link. Just copy and update the content from another news item.
Send out an announcement to the pike mailing list!

Notes about Bundles

(Note: this no longer applies) 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 :)

š 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