Difference between revisions of "Release Template"

From Free Pascal wiki
Jump to navigationJump to search
m (util*.zip built within release, not copied from old)
m (→‎See also: Fix broken page link; add categories)
 
(54 intermediate revisions by 7 users not shown)
Line 1: Line 1:
 +
=== Release Issues ===
 +
 +
The issues page is [[Issues x.y.z]]    (from [[Issues Template]] )
 +
 +
=== Release preparations ===
 +
 +
# For major versions check [[Release engineering#Major versions|major versions to do]]
 +
# Send a mail to fpc-devel to announce that the fixes branch is frozen for the benefit of committers that are not on core (or do not read it regularly)
 +
#  Agree on deadline for changes and date for release candidate building
 +
## Contact platform maintainers who are not subscribed to the core list and notify them about upcoming release and ask them for their inputs into the release schedule
 +
### Olivier Coursiere - Haiku
 +
### Karl-Michael Schindler - Mac OS X - fink
 +
## [[#FPC-x.y.zrc1]] deadline:
 +
## [[#FPC-x.y.z]] deadline:
 +
#  Check the [[Detailed x.y.z Todo]] list for the particular release (should be linked from [[To Do lists]]) for status of individual todo items
 +
#  Check status of [http://bugs.freepascal.org/roadmap_page.php bugs assigned to that particular release] in the bugtracker
 +
#  New page in Wiki named "Release_x.y.z" for release procedure with steps needed and their status (based on [[Release Template]]), at the beginning consisting of (at least) RC1 and final release sections. If it is a final release add a link it to  [[Releasing]]
 +
#  Create new page in Wiki with issue log for documentation of issues encountered in release candidates and their status ("Issues_x.y.z" based on [[Issues Template]])
 +
# Move merged changes from [[User Changes Trunk]] to the appropriate [[User Changes x.y.z]] page, possibly adding changes that were merged but not added to the trunk page, plus update the reference to the changes in previous release from the page for trunk so that it refers the page with changes for the new release
 +
# Update the version number/svn revision of all bug reports in mantis for which the patches were merged but that have not yet been updated (for http://bugs.freepascal.org/changelog_page.php )
 +
#  Ask platform maintainers and [[External_maintainers|external maintainers]] about including their platforms/builds in the new release
 
#  Check and update all .msg files
 
#  Check and update all .msg files
 
## errore.msg
 
## errore.msg
Line 6: Line 27:
 
## errorr.msg
 
## errorr.msg
 
## errorrw.msg
 
## errorrw.msg
 +
## errorues.msg
 
## errores.msg
 
## errores.msg
# New directories
+
## errorct.msg
## Create new directories on FTP and set permission to 700 (using a script ...?)
+
## errorhe.msg
## Copy the extra files (asld*.zip, gdb*.zip, make*.zip) from the old release
+
## errorheu.msg
 +
## errorptd.msg
 +
## errorptw.msg
 +
## errorpli.msg
 +
## errorpl.msg
 +
## errorid.msg
 
#  Check tools
 
#  Check tools
## Check version of the above mentioned tools (GNU tools, helper DLLs, UPX, etc.), and decide whether it isn't time to update some of these tools
+
## Check version of the above mentioned tools (GNU tools, helper DLLs, UPX, etc.), and decide whether it isn't time to update some of these tools. See [[helper tools]]
 
## Repackage and upload additional tools where needed
 
## Repackage and upload additional tools where needed
#  Update version number in the appropriate CVS branch
+
#  Update whatsnew.txt (/install/doc/whatsnew.txt)
 +
#  Find testers
 +
## Create a [[Testers_x.y.z|testers]] page in Wiki (based on [[Testers Template]])
 +
## Ask in fpc-devel list for volunteers interested in testing the individual platforms / builds and list them on the newly created page (they can add themselves)
 +
#  Update path and file names in /install/macosx/*.info for the new version
 +
#  Update path and file names in /install/fpc.ist for the new version
 +
#  Finish all source file updates
 +
# convert /html/faq.fp to /install/doc/faq.htm and /install/doc/faq.txt ([[Release engineering#Convert_the_faq.adp_to_faq.htm_and_faq.txt|more info]])
 +
 
 +
=== RC1 ===
 +
 
 +
-- Below is a template for every version
 +
 
 +
#  New directories ([[Release engineering#Create_directories_on_ftp|more info]])
 +
## Create new directories on ftp (/pub/fpc/beta/X.Y.Z-rcN or /pub/fpc/dist/X.Y.Z and cpu-os under that)
 +
## Copy the extra files (asld*.zip, gdb*.zip, make*.zip) from previous release (unless updated with new versions)
 +
#  Add new section for the upcoming build in /install/debian/changelog ([[Release engineering#Building_a_deb|more info]])
 +
#  Create new branch in SVN (release_X_Y_Z_rcN or release_X_Y_Z) ([[Release engineering#Tag_version|more info]])
 +
#  Update version number in release branch (and, if necessary also in main branch (trunk or fixes)) ([[Release engineering#Update_the_version-number|more info]])
 
## /compiler/version.pas
 
## /compiler/version.pas
 
## /install/doc/readme.txt
 
## /install/doc/readme.txt
## /install/fpinst/install.dat (header + cfg template)
+
## /install/doc/whatsnew.txt
## /install/fpinst/install.pas (installer version)
+
## /installer/install.dat (header)
## /install/fpc-docs.spec
+
## /installer/install.pas (installer version)
## /install/fpc.spec
 
## /install/install.sh
 
## /html/faq.fp (things like "the latest version is ...")
 
## convert /html/faq.fp to /install/doc/faq.htm and /install/doc/faq.txt
 
 
## /docs/fpc.sty (macro fpcversion)
 
## /docs/fpc.sty (macro fpcversion)
# Update whatsnew.txt (/install/doc/whatsnew.txt)
+
## All Makefile.fpc files containing version=... (plus regenerate all corresponding Makefiles) ([[Release engineering#Version_number_of_the_Makefiles|more info]])
# Finishing all source file updates
+
## All version-numbers in fpmake.pp files ([[Release engineering#Version_number_of_the_fpmake_files|more info]])
# Tag CVS with RELEASE_?_?_?
+
# Create and upload exported fpcbuild ([[Release engineering#Create_the_source_zips|more info]])
# Create and upload zip files for GO32v2
+
## fpcbuild-%{version}.zip
# Create and upload zip files for OS/2
+
## fpcbuild-%{version}.tar.gz
# Create and upload zip files for Win32
+
## fpc-%{version}-source.zip
# Create and upload tar files for FreeBSD
+
## fpc-%{version}-source.tar.gz
# Create and upload tar files for Linux
+
# Create and upload the documentation ([[Release engineering#Documentation building and LaTeX limits|more info]])
## i386
+
## doc-pdf.zip
## powerpc
 
## sparc
 
## x86-64
 
## arm
 
# Create and upload Linux RPMs
 
## i386
 
## sparc
 
## x86-64
 
## powerpc
 
## arm
 
# Create and upload Linux DEBs (ask DEB maintainer)
 
## i386
 
## sparc
 
## x86-64
 
## powerpc
 
## arm
 
# Create and upload the documentation
 
## docs-pdf.zip
 
 
## doc-html.zip
 
## doc-html.zip
## doc-htm.zip
+
## <i>doc-htm.zip</i> (not included)
## docs-txt.zip
+
## doc-txt.zip
# Create and upload source zips
+
## doc-ps.zip
# Create and upload source tars
+
## doc-pdf.tar.gz
# Run makereleasezips
+
## doc-html.tar.gz
# Test the GO32v2 release
+
## doc-ps.tar.gz
## dos???.zip installation
+
# Create and upload source zips ([[Release engineering#Create_the_source_zips|more info]])
## dos???full.zip installation (over the previously installed dos???.zip to simulate updates)
+
## short name version for binary packages
## make sure readme.txt & whatsnew.txt are for the current version
+
## docs source (including link for short name version)
## run all executables in /bin/go32v2 (no params)
+
## long name version for binary packages
## make cycle with newly installed binaries and sources
+
# Create and upload binary releases (place the name of the person who agreed to build a release behind the name of the target below)
## run testsuite
+
#* i386-go32v2/basic zip (just binaries)
## open the installed hello.pp in IDE
+
#* i386-go32v2/full zip (including docs and sources)
## make a minor change in the demo in IDE & save it
+
#* i386-os2/basic zip    (just binaries)
## view documentation in IDE, traverse 2-3 pages (at least one with screenshots)
+
#* i386-os2/full zip    (including docs and sources)
## compile the demo file in IDE
+
#* i386-win32/exe
## run the demo within the IDE (debugger)
+
#* x86_64-win64/exe
# Test the OS/2 release
+
#* arm-wince/exe (cross-release)
## os2???.zip installation
+
#* arm-symbian (cross-release)
## os2???full.zip installation (over the previously installed os2???.zip to simulate updates)
+
#* i386-symbian (cross-release)
## make sure readme.txt & whatsnew.txt are for the current version
+
#* arm-gba (cross-release)
## run all executables in /bin/os2 (no params)
+
#* arm-nds (cross-release)
## make cycle with newly installed binaries and sources
+
#* powerpc-wii (cross-release)
## run testsuite
+
#* i386-freebsd/tgz
## open the installed hello.pp in IDE
+
#* i386-linux/tar        ([[Release engineering#Linux|more info]])
## make a minor change in the demo in IDE & save it
+
#* i386-linux/deb        ([[Release engineering#Linux|more info]])
## view documentation in IDE, traverse 2-3 pages (at least one with screenshots)
+
#* i386-linux/rpm        ([[Release engineering#Linux|more info]])
## compile the demo file in IDE
+
#* x86_64-linux/tar      ([[Release engineering#Linux|more info]])
## run the demo within the IDE (debugger)
+
#* x86_64-linux/deb      ([[Release engineering#Linux|more info]])
# Test the Win32 release
+
#* x86_64-linux/rpm      ([[Release engineering#Linux|more info]])
## w32???.zip installation
+
#* powerpc-linux/tar    ([[Release engineering#Linux|more info]])
## w32???full.zip installation
+
#* powerpc64-linux/tar  ([[Release engineering#Linux|more info]])
## dosw32???full.zip installation (over the previously installed w32???full.zip to simulate updates)
+
#* powerpc-macosx/dmg
## make sure readme.txt & whatsnew.txt are for the current version
+
#* i386-macosx/dmg
## run all executables in /bin/win32 and /bin/go32v2 (without parameters)
+
#* i386->powerpc-macosx/dmg
## make cycle with newly installed binaries and sources
+
#* i386->ios-macosx/dmg
## run testsuite
+
#* x86_64-macosx/.info for fink
## open the installed hello.pp in IDE
+
#* powerpc-macos
## make a minor change in the demo in IDE & save it
+
#* sparc-linux/tar       ([[Release engineering#Linux|more info]])
## view documentation in IDE, traverse 2-3 pages (at least one with screenshots)
+
#* sparc-linux/deb      ([[Release engineering#Linux|more info]])
## compile the demo file in IDE
+
#* arm-linux/tar (cross-release)
## run the demo within the IDE (debugger)
+
#* powerpc-morphos
# Test the FreeBSD release
+
#* powerpc-amiga
## FreeBSD tar installation
+
#* i386-netware
## make sure readme.txt & whatsnew.txt are for the current version
+
#* i386-netwlibc
## run all executables in /bin/freebsd (no params)
+
#* i386-haiku
## make cycle with newly installed binaries and sources
+
#* i386-sunos/tar
## run testsuite
+
#* sparc-sunos/tar
## open the installed hello.pp in IDE
+
# Get it tested
## make a minor change in the demo in IDE & save it
+
## Ask dedicated testers for testing their platforms
## view documentation in IDE, traverse 2-3 pages (at least one with screenshots)
+
## Consider announcing availability of the new RC in fpc-devel list
## compile the demo file in IDE
+
# Keep track of testing in [[Testers_x.x.x|the wiki]]
## run the demo within the IDE (debugger)
+
 
# Test Linux DEBs
+
-- End of template for every version
## Linux DEBs installation
+
 
## make sure readme.txt & whatsnew.txt are for the current version
+
=== RC2 ===
## run all executables in /bin/linux (no params)
+
 
## make cycle with newly installed binaries and sources
+
# Section for new RC on release pages in Wiki
## run testsuite
+
## Release procedure
## open the installed hello.pp in IDE
+
## Issue log
## make a minor change in the demo in IDE & save it
+
# Look at unmerged changes in fpc and fpcbuild since the last RC and consider/ask for necessity of their inclusion in the release
## view documentation in IDE, traverse 2-3 pages (at least one with screenshots)
+
 
## compile the demo file in IDE
+
-- Template from above
## run the demo within the IDE (debugger)
+
 
# Test Linux RPMs
+
=== Final release ===
## Linux RPMs installation
+
 
## make sure readme.txt & whatsnew.txt are for the current version
+
# Look at unmerged changes in fpc and fpcbuild since the last RC and consider/ask for necessity of their inclusion in the release (only cosmetic changes should be included, otherwise a new RC is needed instead of final release)
## run all executables in /bin/linux (no params)
+
# Check all bugreports marked fixed with the previous fixes version, or trunk if they apply to the release. (iow if the release packages the fix). If they are fixed, set their "fixed in version" setting to the release version, and update the "fixed in revision" to the revision the fix was merged to release_ or fixes_ branch.
## make cycle with newly installed binaries and sources
+
 
## run testsuite
+
-- Template from above
## open the installed hello.pp in IDE
+
 
## make a minor change in the demo in IDE & save it
+
=== Going public ===
## view documentation in IDE, traverse 2-3 pages (at least one with screenshots)
+
 
## compile the demo file in IDE
+
# Make new version numbers (release plus next odd patch number for continuing fixes) available in bug tracker (don't forget to set releases to "released", or they won't be visible to users.)
## run the demo within the IDE (debugger)
+
# Make new version numbers (release plus next odd patch number for continuing fixes) available in testsuite db
# Test Linux tar release
+
# Make new files on FTP available to wide public
## Linux tar installation
+
## <i>update symlinks</i> (no symlinks any more?)
## make sure readme.txt & whatsnew.txt are for the current version
+
## Move the releases older than 18 months to the olddist/<version> dir.
## run all executables in /bin/linux (no params)
+
## Publish files on SourceForge.net
## make cycle with newly installed binaries and sources
+
### Upload files to SourceForge.net and add them to new "releases" for individual platforms
## run testsuite
+
### Mark the latest whatsnew.txt file as a "Release info" file (using properties of that file in File Manager pages)
## open the installed hello.pp in IDE
+
### Select this release info file for the respective folders containing the new release
## make a minor change in the demo in IDE & save it
+
### Check that the right files are selected as default for the individual platforms recognized by SourceForge.net (use the latest readme.txt as the default download for "All other")
## view documentation in IDE, traverse 2-3 pages (at least one with screenshots)
+
### Make new "releases" on SourceForge.net accessible for users (change status to "active")
## compile the demo file in IDE
+
### Allow automated notifications on individual SourceForge.net file release pages to be sent
## run the demo within the IDE (debugger)
+
# Submit darwin packages to fink
# Check PDF documentation (open all files)
+
# Update WWW pages
# Check HTML documentation
 
# Check TXT documentation
 
# Read updated text files as distributed in release zip files
 
## readme.txt
 
## faq.txt
 
## whatsnew.txt
 
# Make new files on FTP available to wide public
 
## open new directories for public access
 
## update symlinks
 
## move the old version to the olddist/<version>
 
# Update WWW pages
 
 
## /html/news.fp
 
## /html/news.fp
## /html/download.fp (links to all individual files & file sizes)
+
## /html/down/* (links to all individual files & file sizes)
 +
## /html/download.fp (version number and list of platforms)
 +
## Search for the old version number (both with and without dots) in all files under /html/down/ (e.g. using grep) and fix where necessary
 
## /html/fpc.fp
 
## /html/fpc.fp
# Check the WWW pages
+
## /html/faq.fp (things like "the latest version is ...")
 +
#  Update docs linked from the WWW server (http://www.freepascal.org/docs.var) to those from the new release
 +
## Unpack the html docs to docs-html on the WWW server
 +
## Unpack the PDF files (without subdirectory) to docs-pdf on ftpmaster
 +
#  Create new fixes branch (only after a major release -  ?.?.0)
 +
## Update version number in the trunk branch (only after a major release -  ?.?.0)
 +
### /compiler/version.pas
 +
### All Makefile.fpc files containing "version=..." (plus regenerate the corresponding Makefiles)
 +
#  Update version number in the fixes branch (increase the patch to next odd number)
 +
## /compiler/version.pas
 +
## all Makefile.fpc files containing "version=..." (plus regenerate the corresponding Makefiles)
 +
Check the WWW pages
 
## make sure http://www.freepascal.org contains the new version already
 
## make sure http://www.freepascal.org contains the new version already
 
## read news.html
 
## read news.html
 
## read fpc.html
 
## read fpc.html
## read download.html and check _all_ links to individual files
+
## read download.html and check links to individual files
# Send announcement to our mailing lists
+
# Send announcement to our mailing lists
# Post announcement on the community site
+
# Post announcement on the community site
# Revise / update /html/future.fp after major versions (?.?.0)
+
# Post announcement on Sourceforge.net (only "Project Administrators" may do it)
 +
#  Make sure that all unfixed issues encountered during RC testing and listed on dedicated page in Wiki are documented in bug tracker too
 +
Revise / update /html/future.fp after major versions (?.?.0)
 +
#  Remove unneeded RC builds from FTP
 +
#  Add the version to the versioncheck in the topfile makefile.
 +
 
 +
=== See also ===
 +
* [[Release engineering]]
 +
* [[Detailed Lazarus release template todo|comparable Lazarus document]]
 +
 
 +
[[Category:FPC release]]
 +
[[Category:FPC development]]
 +
[[Category:Release engineering]]

Latest revision as of 05:15, 26 August 2020

Release Issues

The issues page is Issues x.y.z (from Issues Template )

Release preparations

  1. For major versions check major versions to do
  2. Send a mail to fpc-devel to announce that the fixes branch is frozen for the benefit of committers that are not on core (or do not read it regularly)
  3. Agree on deadline for changes and date for release candidate building
    1. Contact platform maintainers who are not subscribed to the core list and notify them about upcoming release and ask them for their inputs into the release schedule
      1. Olivier Coursiere - Haiku
      2. Karl-Michael Schindler - Mac OS X - fink
    2. #FPC-x.y.zrc1 deadline:
    3. #FPC-x.y.z deadline:
  4. Check the Detailed x.y.z Todo list for the particular release (should be linked from To Do lists) for status of individual todo items
  5. Check status of bugs assigned to that particular release in the bugtracker
  6. New page in Wiki named "Release_x.y.z" for release procedure with steps needed and their status (based on Release Template), at the beginning consisting of (at least) RC1 and final release sections. If it is a final release add a link it to Releasing
  7. Create new page in Wiki with issue log for documentation of issues encountered in release candidates and their status ("Issues_x.y.z" based on Issues Template)
  8. Move merged changes from User Changes Trunk to the appropriate User Changes x.y.z page, possibly adding changes that were merged but not added to the trunk page, plus update the reference to the changes in previous release from the page for trunk so that it refers the page with changes for the new release
  9. Update the version number/svn revision of all bug reports in mantis for which the patches were merged but that have not yet been updated (for http://bugs.freepascal.org/changelog_page.php )
  10. Ask platform maintainers and external maintainers about including their platforms/builds in the new release
  11. Check and update all .msg files
    1. errore.msg
    2. errord.msg
    3. errorf.msg
    4. errorn.msg
    5. errorr.msg
    6. errorrw.msg
    7. errorues.msg
    8. errores.msg
    9. errorct.msg
    10. errorhe.msg
    11. errorheu.msg
    12. errorptd.msg
    13. errorptw.msg
    14. errorpli.msg
    15. errorpl.msg
    16. errorid.msg
  12. Check tools
    1. Check version of the above mentioned tools (GNU tools, helper DLLs, UPX, etc.), and decide whether it isn't time to update some of these tools. See helper tools
    2. Repackage and upload additional tools where needed
  13. Update whatsnew.txt (/install/doc/whatsnew.txt)
  14. Find testers
    1. Create a testers page in Wiki (based on Testers Template)
    2. Ask in fpc-devel list for volunteers interested in testing the individual platforms / builds and list them on the newly created page (they can add themselves)
  15. Update path and file names in /install/macosx/*.info for the new version
  16. Update path and file names in /install/fpc.ist for the new version
  17. Finish all source file updates
  18. convert /html/faq.fp to /install/doc/faq.htm and /install/doc/faq.txt (more info)

RC1

-- Below is a template for every version

  1. New directories (more info)
    1. Create new directories on ftp (/pub/fpc/beta/X.Y.Z-rcN or /pub/fpc/dist/X.Y.Z and cpu-os under that)
    2. Copy the extra files (asld*.zip, gdb*.zip, make*.zip) from previous release (unless updated with new versions)
  2. Add new section for the upcoming build in /install/debian/changelog (more info)
  3. Create new branch in SVN (release_X_Y_Z_rcN or release_X_Y_Z) (more info)
  4. Update version number in release branch (and, if necessary also in main branch (trunk or fixes)) (more info)
    1. /compiler/version.pas
    2. /install/doc/readme.txt
    3. /install/doc/whatsnew.txt
    4. /installer/install.dat (header)
    5. /installer/install.pas (installer version)
    6. /docs/fpc.sty (macro fpcversion)
    7. All Makefile.fpc files containing version=... (plus regenerate all corresponding Makefiles) (more info)
    8. All version-numbers in fpmake.pp files (more info)
  5. Create and upload exported fpcbuild (more info)
    1. fpcbuild-%{version}.zip
    2. fpcbuild-%{version}.tar.gz
    3. fpc-%{version}-source.zip
    4. fpc-%{version}-source.tar.gz
  6. Create and upload the documentation (more info)
    1. doc-pdf.zip
    2. doc-html.zip
    3. doc-htm.zip (not included)
    4. doc-txt.zip
    5. doc-ps.zip
    6. doc-pdf.tar.gz
    7. doc-html.tar.gz
    8. doc-ps.tar.gz
  7. Create and upload source zips (more info)
    1. short name version for binary packages
    2. docs source (including link for short name version)
    3. long name version for binary packages
  8. Create and upload binary releases (place the name of the person who agreed to build a release behind the name of the target below)
    • i386-go32v2/basic zip (just binaries)
    • i386-go32v2/full zip (including docs and sources)
    • i386-os2/basic zip (just binaries)
    • i386-os2/full zip (including docs and sources)
    • i386-win32/exe
    • x86_64-win64/exe
    • arm-wince/exe (cross-release)
    • arm-symbian (cross-release)
    • i386-symbian (cross-release)
    • arm-gba (cross-release)
    • arm-nds (cross-release)
    • powerpc-wii (cross-release)
    • i386-freebsd/tgz
    • i386-linux/tar (more info)
    • i386-linux/deb (more info)
    • i386-linux/rpm (more info)
    • x86_64-linux/tar (more info)
    • x86_64-linux/deb (more info)
    • x86_64-linux/rpm (more info)
    • powerpc-linux/tar (more info)
    • powerpc64-linux/tar (more info)
    • powerpc-macosx/dmg
    • i386-macosx/dmg
    • i386->powerpc-macosx/dmg
    • i386->ios-macosx/dmg
    • x86_64-macosx/.info for fink
    • powerpc-macos
    • sparc-linux/tar (more info)
    • sparc-linux/deb (more info)
    • arm-linux/tar (cross-release)
    • powerpc-morphos
    • powerpc-amiga
    • i386-netware
    • i386-netwlibc
    • i386-haiku
    • i386-sunos/tar
    • sparc-sunos/tar
  9. Get it tested
    1. Ask dedicated testers for testing their platforms
    2. Consider announcing availability of the new RC in fpc-devel list
  10. Keep track of testing in the wiki

-- End of template for every version

RC2

  1. Section for new RC on release pages in Wiki
    1. Release procedure
    2. Issue log
  2. Look at unmerged changes in fpc and fpcbuild since the last RC and consider/ask for necessity of their inclusion in the release

-- Template from above

Final release

  1. Look at unmerged changes in fpc and fpcbuild since the last RC and consider/ask for necessity of their inclusion in the release (only cosmetic changes should be included, otherwise a new RC is needed instead of final release)
  2. Check all bugreports marked fixed with the previous fixes version, or trunk if they apply to the release. (iow if the release packages the fix). If they are fixed, set their "fixed in version" setting to the release version, and update the "fixed in revision" to the revision the fix was merged to release_ or fixes_ branch.

-- Template from above

Going public

  1. Make new version numbers (release plus next odd patch number for continuing fixes) available in bug tracker (don't forget to set releases to "released", or they won't be visible to users.)
  2. Make new version numbers (release plus next odd patch number for continuing fixes) available in testsuite db
  3. Make new files on FTP available to wide public
    1. update symlinks (no symlinks any more?)
    2. Move the releases older than 18 months to the olddist/<version> dir.
    3. Publish files on SourceForge.net
      1. Upload files to SourceForge.net and add them to new "releases" for individual platforms
      2. Mark the latest whatsnew.txt file as a "Release info" file (using properties of that file in File Manager pages)
      3. Select this release info file for the respective folders containing the new release
      4. Check that the right files are selected as default for the individual platforms recognized by SourceForge.net (use the latest readme.txt as the default download for "All other")
      5. Make new "releases" on SourceForge.net accessible for users (change status to "active")
      6. Allow automated notifications on individual SourceForge.net file release pages to be sent
  4. Submit darwin packages to fink
  5. Update WWW pages
    1. /html/news.fp
    2. /html/down/* (links to all individual files & file sizes)
    3. /html/download.fp (version number and list of platforms)
    4. Search for the old version number (both with and without dots) in all files under /html/down/ (e.g. using grep) and fix where necessary
    5. /html/fpc.fp
    6. /html/faq.fp (things like "the latest version is ...")
  6. Update docs linked from the WWW server (http://www.freepascal.org/docs.var) to those from the new release
    1. Unpack the html docs to docs-html on the WWW server
    2. Unpack the PDF files (without subdirectory) to docs-pdf on ftpmaster
  7. Create new fixes branch (only after a major release - ?.?.0)
    1. Update version number in the trunk branch (only after a major release - ?.?.0)
      1. /compiler/version.pas
      2. All Makefile.fpc files containing "version=..." (plus regenerate the corresponding Makefiles)
  8. Update version number in the fixes branch (increase the patch to next odd number)
    1. /compiler/version.pas
    2. all Makefile.fpc files containing "version=..." (plus regenerate the corresponding Makefiles)
  9. Check the WWW pages
    1. make sure http://www.freepascal.org contains the new version already
    2. read news.html
    3. read fpc.html
    4. read download.html and check links to individual files
  10. Send announcement to our mailing lists
  11. Post announcement on the community site
  12. Post announcement on Sourceforge.net (only "Project Administrators" may do it)
  13. Make sure that all unfixed issues encountered during RC testing and listed on dedicated page in Wiki are documented in bug tracker too
  14. Revise / update /html/future.fp after major versions (?.?.0)
  15. Remove unneeded RC builds from FTP
  16. Add the version to the versioncheck in the topfile makefile.

See also