  
  [1X2 [33X[0;0YPreparing [5XGAP[105X[101X[1X Releases[133X[101X
  
  [33X[0;0YThis  chapter  documents  various  tasks  for preparing a major, minor or an
  update  [5XGAP[105X  release.  To  clarify  the terminology, releasing 4.X.Y+1 after
  4.X.Y  is called a [21Xminor release[121X and releasing 4.X+1.Y after 4.X.Z is called
  a  [21Xmajor  release[121X.  An  [21Xupdate release[121X means releasing the latest officially
  distributed  version  of  the  core [5XGAP[105X system with new and updated packages
  (thus, the version number of the core [5XGAP[105X system stays the same).[133X
  
  [33X[0;0YThe  wrapping  and  publication  processes  are essentially the same for all
  three  kinds  of releases with some minor differences. For example, there is
  some  more work to set up new paths on the ftp server for the major release,
  and there is no need to update main [5XGAP[105X manuals for the update release.[133X
  
  
  [1X2.1 [33X[0;0YCommitting changes for the next minor or major release[133X[101X
  
  
  [1X2.1-1 [33X[0;0YAdding changes to the release branch[133X[101X
  
  [33X[0;0YChanges  that  should  appear in the next release should first appear in the
  the [9Xstable[109X branch for the next minor release or in the [9Xmaster[109X branch for the
  next  major  release. Normally they may first be developed and documented in
  feature   branches,  then  tested  and  only  after  that  merged  into  the
  appropriate release branch.[133X
  
  
  [1X2.1-2 [33X[0;0YDocument your changes[133X[101X
  
  [33X[0;0YThe  [11Xdev/Updates[111X directory is used to describe changes intended for the next
  release.  It  contains  the  [11XREADME[111X  file  explaining in more details how to
  document changes, and two templates: [11Xtemplate-long[111X with explanatory comments
  and  [11Xtemplate-short[111X  without  them.  To document a change, copy one of these
  templates  to  an appropriately named new file and fill in the details. This
  should be done in the same branch where the change itself has been developed
  in  order  to  keep  changes and their documentation together and facilitate
  tracking those changes which are ready for the release.[133X
  
  [33X[0;0YDuring  the  release preparation, files with these descriptions will be used
  to  compose  the  overview  of  changes introduced in the release. When they
  include test code, it will be used to extend the test file [11Xtst/bugfix.tst[111X.[133X
  
  [33X[0;0YDocumenting  changes,  do  [13Xnot[113X describe the wrong behaviour in present tense
  like in:[133X
  
  [30X    [33X[0;6Y[21XFunction [10XXYZ[110X returns the wrong result when computing [10XABC[110X.[121X[133X
  
  [33X[0;0YRather, write it like in these examples:[133X
  
  [30X    [33X[0;6Y[21XFunction [10XXYZ[110X returned the wrong result when computing [10XABC[110X.[121X[133X
  
  [30X    [33X[0;6Y[21XFixed  an  error  in function [10XXYZ[110X which returned the wrong result when
        computing [10XABC[110X.[121X[133X
  
  [30X    [33X[0;6Y[21XFunction [10XXYZ[110X now returns the correct result when computing [10XABC[110X.[121X[133X
  
  [33X[0;0YOtherwise, it will sound as if we knowingly introduced a new bug.[133X
  
  [33X[0;0YPlease  assume  that  the text from your description will be pasted verbatim
  into   the   overview   of   changes  for  the  release  announcement  (only
  cross-references and other needed [5XGAPDoc[105X markup will be added).[133X
  
  [33X[0;0YAfter the release, descriptions of those changes from [10Xdev/Updates[110X which made
  their  way  into  the release should be moved to a new directory with a name
  containing  the release version (e.g. [10Xdev/Updates4.5.7[110X) using [10Xgit mv[110X command
  to  keep them under version control. The [11Xdev/Updates[111X directory in the branch
  from  which  the  release  has  been  made must be reset to contain only the
  [11XREADME[111X  file  and  templates  (and possibly descriptions of changes that has
  been  added  there  after  the  release but before such ressetting will take
  place).[133X
  
  [33X[0;0YWARNING:  The  content  of  the  [10Xdev/Updates[110X  directory  may  look different
  dependently  on  the  branch!  For example, in the integration branch it may
  list changes ready to both next minor and major releases, as well as changes
  merged  into  the  integration branch for testing. It is important to update
  your  clone of the repository to the proper branch (normally, [9Xstable[109X) before
  resetting [10Xdev/Updates[110X.[133X
  
  
  [1X2.2 [33X[0;0YWrapping Archives for a Release or Update[133X[101X
  
  
  [1X2.2-1 [33X[0;0YWhat you need to start[133X[101X
  
  [33X[0;0YHere  is  an  overview  about the hard- and software needed for the wrapping
  process (at least with the currently available scripts and tools).[133X
  
  [30X    [33X[0;6Ya UNIX/Linux machine[133X
  
  [30X    [33X[0;6Ya disc partition with at least several GB of space[133X
  
  [30X    [33X[0;6Ythe standard [10Xsh[110X shell and basic UNIX utilities like [10Xcp[110X, [10Xmv[110X or [10Xcmp[110X[133X
  
  [30X    [33X[0;6Y[10Xgit[110X[133X
  
  [30X    [33X[0;6Ya TeX installation (which can process big files)[133X
  
  [30X    [33X[0;6Ya C-compiler and [10Xmake[110X[133X
  
  [30X    [33X[0;6Y[10Xtar[110X,  [10Xgzip[110X,  [10Xbzip2[110X,  [10Xzip[110X,  and  [10Xpython[110X (for repacking into the various
        formats)[133X
  
  [30X    [33X[0;6Yan installed [5XGAP[105X[133X
  
  [30X    [33X[0;6Ypersons who can provide Windows binaries of the [5XGAP[105X kernel[133X
  
  [33X[0;0YThe  following  descriptions will explain what has to be done in the various
  steps,   and   will   mention   some   tools  which  are  available  in  the
  [11Xdev/DistributionUpdate/dist45[111X  directory of the [5XGAP[105X git repository (the name
  [11Xdist45[111X  reflects  that  these tools were revised for the [5XGAP[105X 4.5 release; we
  are continuing to use them to produce all subseqent releases).[133X
  
  
  [1X2.2-2 [33X[0;0YBefore the actual wrapping[133X[101X
  
  [33X[0;0YHere  we describe preparational steps for wrapping a minor or major release.
  Since  an  update  release has no changes in the core [5XGAP[105X system, to wrap an
  update release you may proceed with steps described in Section [14X2.2-3[114X.[133X
  
  [8XRun tests on release branch.[108X
        [33X[0;6YBefore  thinking about wrapping apply all the standard tests described
        in  Chapter  [14X6[114X to a checked out git release branch and make sure there
        are no problems. (But also do the tests again later, starting with the
        archives which will be actually delivered to the users!)[133X
  
  [8XEdit variables in [11Xsetvar*[111X files.[108X
        [33X[0;6YFor  each  of  the  three  release types, some basic variables for the
        scripts  used  below are set in the files [11Xsetvarmajor[111X, [11Xsetvarminor[111X and
        [11Xsetvarupdate[111X  in  the  [11Xdev/DistributionUpdate/dist45[111X directory. Follow
        instructions  from  that  files  to  adjust the variables as required.
        Normally  you  will  need to change only one or two lines with version
        numbers  and do not need to edit anything else, except when setting up
        release  wrapping  on  a new machine. In that case, choose a directory
        for  the  wrapping  which  can  hold  at  least several GB of data and
        specify it as [10XDISTROOT[110X. Find the path to the directory with the merged
        package  archive  (we assume that it is available locally) and specify
        it as [10XMERGEDPKGLOC[110X.[133X
  
  [8XExtract test code from [11XUpdate[111X file.[108X
        [33X[0;6YChanges  from  previous version(s) are accumulated in individual files
        in the [11Xdev/Updates[111X directory, as explained in [14X2.1-2[114X.[133X
  
        [33X[0;6YTest  code  contained  there  may  be  tested  regularly in the period
        between  releases using the [10Xtestupdates[110X target from the [5XGAP[105X test suite
        (see Chapter  [14X6[114X) to ensure that it works in various settings.[133X
  
        [33X[0;6YThe  test code may be copied into [11Xtst/bugfix.tst[111X at any stage, as soon
        as  it  is  clear  that the relevant change will be a part of the next
        release.  At latest, it should appear in the version of [11Xtst/bugfix.tst[111X
        which  will  be actually tested in the release candidate and delivered
        to  the  users  (exceptions may be made for the test code which may be
        checked   only  interactively  or  requies  a  very  specific  testing
        environment).[133X
  
        [33X[0;6YUsually,  copying  of  the  test  code  to  [11Xtst/bugfix.tst[111X  may happen
        gradually  in  several  iterations  if  there will be several wrapping
        attempts;  it  can  be left out while the wrapped archives are not yet
        expected to become release candidates and were just produced as a part
        of nightly/weekly tests.[133X
  
        [33X[0;6YRemark:  formerly  it  was  possible  to  use  the  file [11XUpdate.g[111X from
        [11Xdev/DistributionUpdate/maindist[111X to extract test code, e.g. by calling[133X
  
  [4X      [32X  GAP input  [32X[104X
          [4Xd := UpdateData("../../Update");;[104X
          [4Xl := FixesAndOthersData(d);;[104X
          [4XPrintTestLines("guck.tst", l);[104X
        [4X[32X[104X
  
        [33X[0;6Yto  extract it to the file [11Xguck.tst[111X. Now [11XUpdate.g[111X needs to be adjusted
        since  test  codes  are  now  distributed  across  multiple files. The
        [10Xtestupdates[110X  target  from the [5XGAP[105X test suite extracts tests from these
        files, but it does not save them to a file, testing them [21Xon the fly[121X.[133X
  
  [8XPrepare an overview of changes for the [11XCHANGES.md[111X file[108X
        [33X[0;6YIf  regular  nightly/weekly  tests  go  well  and  you  hope to wrap a
        suitable  release  candidate,  you may start to prepare an overview of
        changes  that will appear in the next release in [11XCHANGES.md[111X, combining
        it from descriptions provided in files from the [11Xdev/Updates[111X directory.[133X
  
        [33X[0;6YYou  may  postpone  this step until the very release, or perform it in
        several  iterations,  keeping track on new entries that will appear in
        the  [11Xdev/Updates[111X directory. You may group various entries together and
        re-order  them  so that entries which are likely to be interesting for
        more  [5XGAP[105X  users  are  closer  to  the  top  of  each  category. While
        converting  plain  text  to  markdown,  add cross-references and other
        markup  as  appropriate. Ideally, you need only to add the markup, and
        the text of descriptions need not further editing, but please evaluate
        it  critically.  At least you may need to change tenses or reorder the
        text  to better fit surrounding items. Also, do not forget to describe
        new  packages  added for the redistribution or packages with essential
        changes in their new versions.[133X
  
        [33X[0;6YRemark:  formerly  it  was  possible to use the file [11XUtil.g[111X to extract
        descriptions  from  the  [11Xdev/Update[111X  file  and  roughly sort them into
        several categories, e.g. by calling[133X
  
  [4X      [32X  GAP input  [32X[104X
          [4Xd := UpdateData("../../Update");;[104X
          [4Xl := FixesAndOthersData(d);;[104X
          [4XPrintDescriptionLines("guck.mixer", l);[104X
        [4X[32X[104X
  
        [33X[0;6Yto  extract it to the file [11Xguck.mixer[111X. Now [11XUtil.g[111X needs to be adjusted
        since  test  codes  are  now distributed across multiple files, and we
        need to produce [5XGAPDoc[105X markup and not Mixer.[133X
  
  
  [1X2.2-3 [33X[0;0YWrapping the archives for the [5XGAP[105X[101X[1X source distribution[133X[101X
  
  [33X[0;0YNow we explain how to wrap the archives of the [5XGAP[105X source distribution (note
  that  the  [5XGAP[105X  binaries  for  Windows  are  not  a  part  of the [5XGAP[105X source
  distribution,  and  they  should  added  to  the [11X-win.zip[111X archive at a later
  step).[133X
  
  [33X[0;0YThe  [5XGAP[105X  source  distribution  will  be  produced  in  the form of [11X.tar.gz[111X,
  [11X.tar.bz2[111X  and  [11X.zip[111X  archives,  and also in the [11X-nobin-win.zip[111X archive whose
  text files have Windows-stile line breaks.[133X
  
  [33X[0;0YTo wrap the archives, change to the [11Xdev/DistributionUpdate/dist45/[111X directory
  of the [9Xstable[109X branch of the [5XGAP[105X git repository, check that you have properly
  set  up  version  numbers  in [11Xsetvar*[111X file(s) as explained in [14X2.2-2[114X and then
  call one of the following:[133X
  
  [4X[32X[104X
    [4Xmake minor[104X
    [4Xmake major[104X
    [4Xmake update[104X
  [4X[32X[104X
  
  [33X[0;0Ydependently on the type of the release that you are going to wrap.[133X
  
  [33X[0;0YWe  will  now  explain in more details which steps will be performed. If not
  specified,    all    files    are    assumed    to    be   from   the   same
  [11Xdev/DistributionUpdate/dist45/[111X directory.[133X
  
  [33X[0;0YFirst,  after  calling  [10Xmake[110X  with the appropriate target, the corresponding
  [11Xsetvar*[111X  file will be copied into the [11Xsetvar[111X file (which may be removed with
  [10Xmake  clean[110X  if  needed). Then the script [11X./doit[111X will be called. This script
  contains  only  calls  to other scripts, arranged in three stages with clean
  interfaces  between them (so, theoretically, each step may be performed on a
  different machine):[133X
  
  [30X    [33X[0;6Ycheckout and archive the release branch;[133X
  
  [30X    [33X[0;6Ymake necessary preparations in the [5XGAP[105X core;[133X
  
  [30X    [33X[0;6Ymerge the [5XGAP[105X core with packages.[133X
  
  [33X[0;0YWe will now describe in some more details what each of the called scripts is
  doing (you don't normally need to call them directly except while debugging;
  calling them out of order is not guaranteed to work!).[133X
  
  [8X[11X./setvar[111X[108X
        [33X[0;6Ysets various environment variables (paths, version numbers, etc.).[133X
  
  [8X[11X./checkoutgit[111X[108X
        [33X[0;6Ycreates  a  new  clone  of  the [5XGAP[105X git repository. Dependently on the
        release  (minor, major or update) it will set the working directory to
        the  [9Xstable[109X  branch,  [9Xmaster[109X  branch or to the revision taggest as the
        last  minor  release respectively. It will also record the revision on
        which  the  working  directory  is based and the time of cloning which
        will be subsequently used in the timestamp.[133X
  
  [8X[11X./classifyfiles[111X[108X
        [33X[0;6Yclassifies files into text and binary files to be included in the main
        archive  or  in  the  tools  archive, or not shipped at all, using the
        Python   script   [11Xclassifyfiles.py[111X  and  files  [11Xpatternscolor.txt[111X  and
        [11Xpatternstextbinary.txt[111X which specify classification rules.[133X
  
  [8X[11X./zipreleasebranch[111X[108X
        [33X[0;6Ywraps  files  from  the  core  [5XGAP[105X  system  that  are  marked  for the
        redistribution into the release branch archive and the tools archive[133X
  
  [8X[11X./zipmetainfo[111X[108X
        [33X[0;6Ywraps  the  meta-information  archive,  containing  the  [11X.servar[111X file,
        details  about  the  checkout  time  and  various lists of files to be
        included. This script completes stage 1.[133X
  
  [8X[11X./unpackreleasebranch[111X[108X
        [33X[0;6Yunpacks  all  three  archives  produced  at  two  preceding steps: the
        release  branch  archive,  the  tools archive and the meta-information
        archive  (at  this  step,  all  files  and subdirectories that are not
        redistributed are already excluded).[133X
  
  [8X[11X./updateversioninfo[111X[108X
        [33X[0;6Yinserts  version  number, release date and other depending information
        (so  these  adjustments  will never appear in the repository; instead,
        after  the  release  we will find the parent revision used to wrap the
        release and will tag it with an appropriate tag).[133X
  
        [33X[0;6YVersion numbers must be adjusted in the following files:[133X
  
        [30X    [33X[0;12Y[11Xconfigure.ac[111X, look at the top of the file[133X
  
  [8X[11X./fixpermissions[111X[108X
        [33X[0;6Ygives  directories [10X755[110X-permissions and files [10X644[110X-permissions, and also
        gives  [10X755[110X-permissions  to  a  few  explicitly listed there executable
        files (so it must be adjusted if new executable files are added to the
        [5XGAP[105X distribution).[133X
  
  [8X[11X./zipgapcore[111X[108X
        [33X[0;6Yproduces   the   [11Xetc/tools.tar.gz[111X  archive,  also  adding  to  it  the
        [11Xgapmacrodoc.pdf[111X  document,  and  then  prepares the archive of the [5XGAP[105X
        core system.[133X
  
  [8X[11X./updatemetainfo[111X[108X
        [33X[0;6Yupdates  the  meta-information  archive,  containing the [11X.servar[111X file,
        details  about  the  checkout  time  and  various lists of files to be
        included. This script completes stage 2.[133X
  
  [8X[11X./unpackgapcore[111X[108X
        [33X[0;6Yunpacks  the  [5XGAP[105X core system archive and the meta-information archive
        produced  by  previous two steps (at this step, the core [5XGAP[105X system is
        exactly  in  the  same  state as will be included in the distribution,
        except hat manuals are yet to be built).[133X
  
  [8X[11X./unpackpackages[111X[108X
        [33X[0;6Yfinds in the location specified in [10XMERGEDPKGLOC[110X and unpacks the latest
        merged  packages archive and its corresponding metainformation archive
        (with, in particular, list of text/binary files).[133X
  
  [8X[11X./checkpermissions[111X[108X
        [33X[0;6Ychecks for potentially problematic file permissions, i.e.:[133X
  
        [30X    [33X[0;12Ydirectories not having 755 permissions;[133X
  
        [30X    [33X[0;12Yfiles not having 644 or 755 permissions;[133X
  
        [30X    [33X[0;12Yfiles  with  755  permissions,  not recognized as executables by
              [11Xfile[111X.[133X
  
        [33X[0;6YThese  situations  may  occur  in  some  packages, since we adjust all
        permissions  in  the core [5XGAP[105X system, but we do not modify permissions
        chosen  by  package authors in case they deliberately use non-standard
        settings.[133X
  
  [8X[11X./makedoc[111X[108X
        [33X[0;6Ybuilds  the  main  [5XGAP[105X manuals (the packages archives were unpacked on
        the  previous  step to ensure that cross-references to package manuals
        will be resolved).[133X
  
  [8X[11X./addmanualfiles[111X[108X
        [33X[0;6Yadds  lists of text and binary [5XGAP[105X documentation files to the lists of
        files  to  be included in the distribution (thus, despite the previous
        step  builds  [5XGAP[105X binaries needed to run [5XGAP[105X to build its manuals, our
        relying  on  [11Xclassifyfiles.py[111X  and  explicit  control  what  has to be
        included  ensures  that  nothing produced by that build will appear in
        the release, except of the manuals themselves).[133X
  
  [8X[11X./zipgapsourcedistro[111X[108X
        [33X[0;6Yproduces  final  [5XGAP[105X source distribution archives in all four formats:
        [11X.tar.gz[111X, [11X.tar.bz2[111X, [11X.zip[111X archives and [11X-nobin-win.zip[111X with Windows-style
        line breaks.[133X
  
  [8X[11X./finalisemetainfo[111X[108X
        [33X[0;6Yproduces the final version of the meta-information archive.[133X
  
  [33X[0;0YNow  archives  with  [5XGAP[105X  source  are ready for testing on as many different
  systems as possible. Recall the test suites described in Chapter [14X6[114X.[133X
  
  
  [1X2.2-4 [33X[0;0YCompiling on Windows with Cygwin[133X[101X
  
  [33X[0;0YTo produce the [11X-win.zip[111X archive with binaries for [5XGAP[105X and some packages, you
  need  the [11X-nobin-win.zip[111X archive with Windows-style line breaks from the [5XGAP[105X
  source distribution produced as described above, and a Windows computer with
  [5XCygwin[105X ([7Xhttps://www.cygwin.com/[107X) installed.[133X
  
  [33X[0;0YUnpack  the  archive,  start  [5XCygwin[105X shell, change to the [5XGAP[105X root directory
  created after unpacking and enter[133X
  
  [4X[32X[104X
    [4X./configure[104X
    [4Xmake cygwin[104X
  [4X[32X[104X
  
  [33X[0;0YThis  will  build [5XGAP[105X executable for Windows. After that, you may also build
  packages  with  kernel  modules  which seem to work under Windows. As in [5XGAP[105X
  4.6,  these  are the following: [5XBrowse[105X, [5Xcvec[105X, [5XEDIM[105X, [5XIO[105X and [5Xorb[105X. Each of them
  supports the standard [10X./configure ; make[110X building procedure.[133X
  
  [33X[0;0YNote  that  there  is  a  nasty  problem  with respect to dynamically linked
  libraries used by cygwin under Windows: There seems to be no working version
  bookkeeping  with DLLs. That is, [5XGAP[105X might not be working on Windows systems
  where  another version than the version against which the [5XGAP[105X executable was
  linked  is installed (at least as long as a process is running that uses the
  other  version  of  [11Xcygwin1.dll[111X). However, we do not see a clean solution to
  this problem.[133X
  
  
  [1X2.3 [33X[0;0YReleasing a new version[133X[101X
  
  [33X[0;0YAfter all archives are wrapped and checked and no more errors are found, one
  has to do the following things to properly publish the release:[133X
  
  [31X1[131X   [33X[0;6YInstall  the  brand new version yourself using one of the produced [5XGAP[105X
        source  distribution  archives (one needs to have this during the next
        few  steps).  The  archive will already have documentation created and
        will  contain  latest released versions of all currently redistributed
        packages. DO NOT USE any versions of packages from other sources![133X
  
  [31X2[131X   [33X[0;6YCopy [11X.tar.bz2[111X [11X.tar.gz[111X, [11X.zip[111X archives, [11X-win.zip[111X and [11X-noreadline-win.zip[111X
        archives  (with  Windows binaries), and also [11X.exe[111X Windows installer to
        the  ftp  server,  distributed  into  directories by the archive type.
        Also,  place  the archive of the core [5XGAP[105X system without packages into
        [11Xftp://ftp.gap-system.org/pub/gap/gap4core/[111X for developers.[133X
  
        [33X[0;6YFrom  this point, the release is considered to be published, since the
        archives are now publicly available.[133X
  
  [31X3[131X   [33X[0;6YPrepare individual archives for the same versions of [5XGAP[105X packages that
        were  included  in  the  release  and copy them to the ftp server. The
        procedure should be explained in more details in Chapter [14X8[114X (while this
        chapter  is  empty, see the [11XDistributionUpdate/PackageUpdate[111X directory
        from the [7Xhttps://github.com/gap-system/gap-distribution[107X repository for
        more    details).    In    brief,    you    should   change   to   the
        [11XDistributionUpdate/PackageUpdate[111X directory of the mentioned repository
        and do the following:[133X
  
        [30X    [33X[0;12Ymark  those  versions  of  packages  which  are  included in the
              release     as    [21Xstable[121X    using    [11X./markStableRevisions[111X    or
              [11X./markAllLatestStable[111X scripts[133X
  
        [30X    [33X[0;12Ymark  all stable versions of packages with the bookmark denoting
              the release, e.g.[133X
  
  [4X            [32X[104X
                [4X    ./markAllStableWithTimestamp gap4r5p6_2012_11_04-18_46[104X
                [4X    [104X
              [4X[32X[104X
  
        [30X    [33X[0;12Ycreate  individual  archives for stable versions of [5XGAP[105X packages
              with [10X./mergePackages all stable[110X[133X
  
        [30X    [33X[0;12Yupdate package manuals for the website with [10X./updatePackageDocs[110X[133X
  
        [30X    [33X[0;12Ygenerate  Mixer  code  for  packages section of the website with
              [10X./writePackageWebInfos[110X[133X
  
        [30X    [33X[0;12Ycopy  package  archives to the ftp server with [10X./CopyToFtpServer[110X
              (this  script  will perform a dry run first, so you will be able
              to check if the list is correct before copying)[133X
  
        [30X    [33X[0;12Yupdate  the  local  clone  of  the [5XGAP[105X website repository to the
              latest   revision,   then   copy   there   package  manuals  and
              autogenerated  Mixer  code  using [10X./CopyToWWW2[110X (this script will
              also  perform  a  dry run first, so you will be able to check if
              everything is right before copying)[133X
  
        [30X    [33X[0;12Ychange  to  the  local clone of the [5XGAP[105X website repository. Copy
              manuals  of  updated  packages  to  the  public website. Revise,
              commit  and  push  changes  in  the files kept under the version
              control.  Some  files  for packages which are just added for the
              redistribution may have to be placed under version control.[133X
  
              [33X[0;12YSince  now  the  autogenerated  data are pushed into the central
              repository,  mosts of the website editing steps listed below may
              be  done  on  another  machine  different  from the one used for
              checking for package updates and wrapping package archives.[133X
  
  [31X4[131X   [33X[0;6YUsing  some clone of the [5XGAP[105X website repository, do further editing as
        necessary:[133X
  
        [30X    [33X[0;12YIn   case   of   a   minor  or  major  release,  read  the  file
              [11Xdev/LinksOfAllHelpSections.g[111X  from  the [9Xstable[109X branch of the [5XGAP[105X
              git  repository  using  your  brand  new installation of the [5XGAP[105X
              version  to  be released (remember to start it with [10X-r[110X option to
              avoid  loading your private packages). This will create the file
              [11XAllLinksOfAllHelpSections.data[111X  which  is needed to create links
              from    the    webpages    into    the    manual.   Now   update
              [11Xlib/AllLinksOfAllHelpSections.data[111X with this new version.[133X
  
        [30X    [33X[0;12YChange  [11Xlib/config[111X  to  update version numbers, release date and
              time, etc.[133X
  
        [30X    [33X[0;12YFor  a  minor  or  major  release  of  [5XGAP[105X  4.X.Y,  add the file
              [11XReleases/4.X.Y.mixer[111X  under  the  version control. You may use a
              similar  file  for the previous release as a template. Links and
              names of the archives (version number) and file sizes have to be
              adjusted   manually.  For  the  specification  of  all  packages
              included     in     the     distribition,     see    the    file
              [11XPackages/pkgstaticlist[111X.  Update  the symlink [11XReleases/index.html[111X
              to  point  to  the new [11XReleases/4.X.Y.html[111X file (you may need to
              run  Mixer  to  create  it  first).  Add  a  new  entry  to  the
              [11XReleases/tree[111X file.[133X
  
              [33X[0;12YFor  an  update  release, you need only to continue the existing
              page  for  the latest release. You may also use previous section
              on  that  page as a template, and find detauls about packages in
              the  file  [11XPackages/pkgstaticlist[111X.  You  do not need to list all
              changed  packages  in  this  case:  listing only new and updated
              packages will suffice.[133X
  
        [30X    [33X[0;12YIf  there  is  a  new  package added for the redistribution, you
              should  edit  [11XPackages/packages.mixer[111X  and  [11XPackages/tree[111X to add
              links  to  its  overview page from the list of packages and from
              the left navigation panel.[133X
  
        [30X    [33X[0;12YChange [11XDownload/index.mixer[111X and [11XDownload/upgrade.mixer[111X to update
              version numbers, the [5XGAP[105X banner etc.[133X
  
        [30X    [33X[0;12YFor        a        major       release       only,       change
              [11XWWW2/Download/Updates/index.mixer[111X:  add  new  entry  for the new
              release with a link to the Changes manual.[133X
  
        [30X    [33X[0;12YUpdate package installation scripts [11XDownload/InstPackages.sh[111X and
              [11XDownload/InstPackages32.sh[111X, if there were any changes.[133X
  
        [30X    [33X[0;12YBuild  a  local  copy  of the website using Mixer, check that it
              works,   then  commit  and  push  all  changes  to  the  central
              repository.  If  need  be  (e.g.  for  major  releases with more
              structural changes), you may use the testing website to check it
              there first. See [14X9[114X for further instructions.[133X
  
  [31X5[131X   [33X[0;6YCopy  the  complete  [11Xdoc[111X directory (of your brand new installation) to
        the public website [11XManuals/doc[111X so that manual links will work.[133X
  
  [31X6[131X   [33X[0;6YIn  the [5XGAP[105X repository, tag what has been released with [10Xv4.X.Y[110X where [10XX[110X
        is  the  major  release number and [10XY[110X is the minor release number (e.g.
        [10Xv4.6.3[110X). The [10Xtag[110X command has the format[133X
  
  [4X      [32X[104X
          [4X     git tag TAGNAME REVISION[104X
          [4X     [104X
        [4X[32X[104X
  
        [33X[0;6Yand  the  revision that should be tagged should be determined from the
        release  wrapping  log.  Normally this should be the tip of the [9Xstable[109X
        branch  at  the  moment  of wrapping the release (not at the moment of
        tagging!).[133X
  
  [31X7[131X   [33X[0;6YUpdate [11Xdev/Updates[111X directory:[133X
  
        [30X    [33X[0;12YCreate  [11Xdev/Update4.X.Y[111X  directory  and  add  it  to the version
              control.[133X
  
        [30X    [33X[0;12YMove   all   files  with  documented  changes  from  [11Xdev/Updates[111X
              directory  to [11Xdev/Update4.X.Y[111X directory using [10Xgit mv[110X command, so
              that  the  only  files  left  in [11Xdev/Updates[111X directory should be
              [11XREADME[111X  and  two  templates  (important to do this in the [9Xstable[109X
              branch, since other branches may have more documented changes).[133X
  
        [30X    [33X[0;12YCommit and push changes.[133X
  
  [31X8[131X   [33X[0;6YEdit variables in [11Xdev/DistributionUpdate/dist45/setvar*[111X files, setting
        the numbers as appropriate for wrapping the next release candidate.[133X
  
  [31X9[131X   [33X[0;6YTest download links and proofread web pages.[133X
  
  [31X10[131X  [33X[0;6YAnnounce  the  new  version in the forum (for the major release, it is
        preferable to wait with the announcement until it will be picked up by
        all alternative distributions as well).[133X
  
