Release 3.2.4

Release Issues

The issues page is Issues 3.2.4 (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
4. 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
5. Olivier Coursiere - Haiku
6. Karl-Michael Schindler - Mac OS X - fink
7. #FPC-3.2.4rc1 deadline:
8. #FPC-3.2.4 deadline:
9. Check the Detailed 3.2.4 Todo list for the particular release (should be linked from To Do lists) for status of individual todo items
10. Check status of bugs assigned to that particular release in the bugtracker
11. New page in Wiki named "Release_3.2.4" 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
12. Create new page in Wiki with issue log for documentation of issues encountered in release candidates and their status ("Issues_3.2.4" based on Issues Template)
13. Move merged changes from User Changes Trunk to the appropriate User Changes 3.2.4 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
14. 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 [https://gitlab.com/freepascal.org/fpc/source/-/issues/?sort=created_date&state=opened&label_name%5B%5D=FixVersion%3A%3A3.3.1&first_page_size=20](https://gitlab.com/freepascal.org/fpc/source/-/issues/?sort=created_date&state=opened&label_name%5B%5D=FixVersion%3A%3A3.3.1&first_page_size=20) )
15. Ask platform maintainers and external maintainers about including their platforms/builds in the new release
16. Check and update all .msg files
17. errore.msg
18. errord.msg
19. errorf.msg
20. errorn.msg
21. errorr.msg
22. errorrw.msg
23. errorues.msg
24. errores.msg
25. errorct.msg
26. errorhe.msg
27. errorheu.msg
28. errorptd.msg
29. errorptw.msg
30. errorpli.msg
31. errorpl.msg
32. errorid.msg
33. Check tools
34. 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
35. Repackage and upload additional tools where needed
36. Update whatsnew.txt (/install/doc/whatsnew.txt)
37. Find testers
38. Create a testers page in Wiki (based on Testers Template)
39. 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)
40. (Update path and file names in /install/macosx/*.info for the new version)
41. (Update path and file names in /install/fpc.ist for the new version)
42. Finish all source file updates
43. 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)
2. Create new directories on ftp (/pub/fpc/beta/X.Y.Z-rcN or /pub/fpc/dist/X.Y.Z and cpu-os under that)
3. Copy the extra files (asld*.zip, gdb*.zip, make*.zip) from previous release (unless updated with new versions)
4. Add new section for the upcoming build in /install/debian/changelog (more info)
5. Create new branch in SVN (release_X_Y_Z_rcN or release_X_Y_Z) (more info)
6. Update version number in release branch (and, if necessary also in main branch (trunk or fixes)) (more info)
7. /compiler/version.pas
8. /install/doc/readme.txt
9. /install/doc/whatsnew.txt
10. /installer/install.dat (header)
11. /installer/install.pas (installer version)
12. /docs/fpc.sty (macro fpcversion)
13. All Makefile.fpc files containing version=... (plus regenerate all corresponding Makefiles) (more info)
14. All version-numbers in fpmake.pp files (more info)
15. Create and upload exported fpcbuild (more info)
16. fpcbuild-%{version}.zip
17. fpcbuild-%{version}.tar.gz
18. fpc-%{version}-source.zip
19. fpc-%{version}-source.tar.gz
20. Create and upload the documentation (more info)
21. doc-pdf.zip
22. doc-html.zip
23. doc-htm.zip (not included)
24. doc-txt.zip
25. doc-ps.zip
26. doc-pdf.tar.gz
27. doc-html.tar.gz
28. doc-ps.tar.gz
29. Create and upload source zips (more info)
30. short name version for binary packages
31. docs source (including link for short name version)
32. long name version for binary packages
33. 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
34. Get it tested
35. Ask dedicated testers for testing their platforms
36. Consider announcing availability of the new RC in fpc-devel list
37. Keep track of testing in the wiki

-- End of template for every version

RC2

1. Section for new RC on release pages in Wiki
2. Release procedure
3. Issue log
4. 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
4. update symlinks (no symlinks any more?)
5. Move the releases older than 18 months to the olddist/<version> dir.
6. Publish files on SourceForge.net
7. Upload files to SourceForge.net and add them to new "releases" for individual platforms
8. Mark the latest whatsnew.txt file as a "Release info" file (using properties of that file in File Manager pages)
9. Select this release info file for the respective folders containing the new release
10. 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")
11. Make new "releases" on SourceForge.net accessible for users (change status to "active")
12. Allow automated notifications on individual SourceForge.net file release pages to be sent
13. Submit darwin packages to fink
14. Update WWW pages
15. /html/news.fp
16. /html/down/* (links to all individual files & file sizes)
17. /html/download.fp (version number and list of platforms)
18. 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
19. /html/fpc.fp
20. /html/faq.fp (things like "the latest version is ...")
21. Update docs linked from the WWW server (http://www.freepascal.org/docs.var) to those from the new release
22. Unpack the html docs to docs-html on the WWW server
23. Unpack the PDF files (without subdirectory) to docs-pdf on ftpmaster
24. Create new fixes branch (only after a major release - ?.?.0)
25. Update version number in the trunk branch (only after a major release - ?.?.0)
26. /compiler/version.pas
27. All Makefile.fpc files containing "version=..." (plus regenerate the corresponding Makefiles)
28. Update version number in the fixes branch (increase the patch to next odd number)
29. /compiler/version.pas
30. all Makefile.fpc files containing "version=..." (plus regenerate the corresponding Makefiles)
31. Check the WWW pages
32. make sure http://www.freepascal.org contains the new version already
33. read news.html
34. read fpc.html
35. read download.html and check links to individual files
36. Send announcement to our mailing lists
37. Post announcement on the community site
38. Post announcement on Sourceforge.net (only "Project Administrators" may do it)
39. Make sure that all unfixed issues encountered during RC testing and listed on dedicated page in Wiki are documented in bug tracker too
40. Revise / update /html/future.fp after major versions (?.?.0)
41. Remove unneeded RC builds from FTP
42. Add the version to the versioncheck in the topfile makefile.

See also

• Release engineering
• comparable Lazarus document

---

From the Free Pascal wiki, page "Release 3.2.4", as the Internet Archive kept it on 2025-01-24, last changed on 2024-07-20. Copyright stays with the author who wrote it, according to the old wiki's Licensing page. If you have concerns about this material, message the admin.