Release engineering

Migration of existing SVN checkout

The existing checkout of the 'fixes_2_0' branch can be switched to the release tag using SVN command "switch", specifically its first variant (see below). However, it's recommended to build in exported sources, not in checked out version.

~/fpc>>> svn sw --help
switch (sw): Update the working copy to a different URL.
usage: 1. switch URL [PATH]
       2. switch --relocate FROM TO [PATH...]

 1. Update the working copy to mirror a new URL within the
 repository.
    This behaviour is similar to 'svn update', and is the way to move
    a working copy to a branch or tag within the same repository.

 2. Rewrite working copy URL metadata to reflect a syntactic change
 only.
    This is used when repository's root URL changes (such as a scheme
    or hostname change) but your working copy still reflects the same
    directory within the same repository.

Create libgdb.a and or binutils

• If you have problems building recent binutils or libgdb's on any *nix, and the error is related to intl.h or libintl.a, reconfigure using ../<srcdir>/configure --disable-nls (assuming you use a separate builddir)
• Some cygwin hints:
  • ensure you've installed gcc, bison and flex
  • use
    ./configure --disable-ide --disable-libgui --disable-install-libgui
    to configure

General notes about release building

To create a build, you always have to start with compiler from the last previous major release (e.g. 2.0.0 for all 2.0.x and 2.2.0 releases, 2.2.0 for 2.2.x, etc.), or the last previous minor release (i.e. you can use 2.0.2 for building 2.0.4).

OS/CPU specific release engineering

FreeBSD specific Release Engineering

Linux

Get sources, usually done with a command like:

 svn export http://svn.freepascal.org/svn/fpcbuild/tags/release_2_0_2 fpcbuild

Get libgdb for your CPU from ftp://ftp.freepascal.org/pub/fpc/contrib/libgdb/, extract it into fpcbuild/fpcsrc/ preserving pathes. Before building please check for files libiberty.a, libopcode.a and libbfd.a. These files are often installed in directories like /usr/lib. The compiler must not be able to find them! The reason is that otherwise the compiler might use the preinstalled ones instead of the ones you put in the libgdb directory, and the preinstalled ones are not compatible with libgdb.a. If the compiler finds and uses these libraries in /usr/lib, the IDE will crash on any debugging attempt.

Get the most recent docs package from the ftp site, it's called docs-pdf.tar.gz and copy it into the fpcbuild/ directory.

Change into fpcbuild/ and execute

 install/makepack

Building an rpm

To build an RPM, change into fpcbuild and execute

 make rpm

the documentation will be built as well and that requires a working Tex installation. To prevent the documentation from being built, execute

 make rpm NODOCS=1

Building a deb

To build an Debian Package,

- Ensure that you have at least installed the following debian packages: dpkg-dev, fakeroot

- Modify the fpcbuild/install/debian/changelog file adding the following

 fpc (2.0.4-rc1) unstable; urgency=low
 
 * release candidate build
 
-- First Last <mail@address.ext>  Thu, 07 Jul 2006 23:44:00 +0100
 

- change into fpcbuild and execute

 make deb

the documentation will be built as well and that requires a working Tex installation. To prevent the documentation from being built, execute

 make deb NODOCS=1

Source zip generation

Change to a temporary directory and execute

 fpcbuild/install/makesource <release version>

e.g.

 fpcbuild/install/makesource 2.0.2

Documentation building and LaTeX limits

A lot of TeTeX distributions are configured to never use more than a very small amount of memory. The values chosen are more of the 486 era (several MBs, while now 256MB is considered "entry level").

The Free Pascal documentation is fairly large, and uses a lot of labels for convenient hyperlinked PDFs and thus hits this limit.

This can be remedied by modiying the save_size line in texmf.conf to

 save_size=10000

Usually, you can also do this by environment variable.

export save_size=10000
pdflatex rtl.tex

Packaging system

See Packaging System and dividing FPC - Lazarus into packages

Testing a release

In general:

1. check all zip/deb/rpm etc files
2. try the installer (if available)
3. make sure readme.txt & whatsnew.txt are for the current version
4. run all executables
5. make cycle with newly installed binaries and sources
6. run testsuite
7. IDE
   1. open the installed hello.pp in IDE
   2. make a minor change in the demo in IDE & save it
   3. view documentation in IDE, traverse 2-3 pages (at least one with screenshots)
   4. compile the demo file in IDE
   5. run the demo within the IDE (debugger)
8. Documentation (open all files)
   1. Check PDF documentation (if available)
   2. Check HTML documentation (if available)
   3. Check TXT documentation (if available)

Target-specific:

1. GO32v2
   1. dos???.zip installation
   2. dos???full.zip installation (over the previously installed dos???.zip to simulate updates)
2. OS/2
   1. os2???.zip installation
   2. os2???full.zip installation (over the previously installed os2???.zip to simulate updates)
3. Win32
   1. Run installer
4. x86_64-linux and i386-linux
   1. Test a .rpm install
   2. Test a .deb install