Release Checklist

This does not take into account the merge of temporary branches to gather the code to be published in a single branch or the tests to ensure the maturity of the code. This step is part of the development and is exceptional.

As the development is Trunk-based, the release is also based on trunk for simplicity.

X.Y.Z is the number of the released version defined by the constant WIKINDX_PUBLIC_VERSION. trunk is not a valid name.

Code preparation and checks

  1. In the event of a change in structure or the addition of a third-party library in a plugin, update:

    • robots.txt
    • phpdoc.xml
    • The list of ignored files.
    • All php scripts that are used for a release
  2. Build the manual of the trunk with the release script release/cli-make-api-manual.php. Is everything that has changed documented? Does the manual build without crashing? Does the release script execute without errors? Fix all issues.

   $ php release/cli-make-api-manual.php
  1. Check the release number in WIKINDX_PUBLIC_VERSION and the changelog.

  2. Change WIKINDX_RELEASE_DATE to the current date and WIKINDX_COPYRIGHT_YEAR to the current year.

  3. Check the internal version number in WIKINDX_INTERNAL_VERSION. Increment it by one (and one only) if a core upgrade is needed.

  4. If the internal version has changed since the last public release, then add the highest of them to WIKINDX_INTERNAL_PUBLIC_VERSION_MAPPING.

  5. Check that WIKINDX_COMPONENTS_COMPATIBLE_VERSION[“plugin”] and $wikindxVersion in compatible plugins have the same value.

  6. Check that the core upgrade stage for this version is complete and functional: database, constants, variables, files, folders, messages, version numbers.

  7. Check that the plugins upgrade for this version is complete and functional: database, constants, variables, files, folders, messages, version numbers.

  8. Check if a code change has changed compatibility. Update WIKINDX_PHP_VERSION_MIN, WIKINDX_PHP_VERSION_MAX, WIKINDX_MYSQL_VERSION_MIN, and WIKINDX_MARIADB_VERSION_MIN.

  9. Check if a code change has changed PHP extensions compatibility. Update \UTILS\listCoreMandatoryPHPExtensions() and \UTILS\listCoreOptionalPHPExtensions() functions.

  10. Check that the changelog of the core is complete.

  11. Check that the changelog of each component is complete.

  12. Update component.json file of components and check their integrity in the admin components panel.

  13. Update the db schema of the Repair Kit (only if the db schema have been changed for this release).

    $ php trunk/cli-dump-repairkit-schema.php
  1. Update translations in SVN and push PHP source files on Transifex via the /home/project-web/wikindx/htdocs/transifex/php directory on the SF WIKINDX Website FTP. Wait for Transifex to update the resources (twice a day). You can force the update by hand but put the PHP file online before. Announce on Transifex a deadline for updating translations before the release.
    $ php trunk/cli-make-translations.php
    $ php release/cli-upload-translation-templates.php
  1. On the translation deadline, download the translated files from Transifex to SVN and compile the translation catalogs.
    $ php release/cli-download-translations.php
    $ php trunk/cli-make-translations.php
  1. Sign components. If the hash of a component changes (use “svn diff” for checking it) then its code has changed. Check that its version number has been incremented and that the changelog is up to date, the component.json file is up to date. Sign them again (the hash doesn’t change if the code doesn’t change).
    $ php trunk/cli-sign-components.php
  1. Commit them to SVN. Step 20 to 23 are optional. In case of error, change the code and restart to step 18.

  2. When the components are up to date, build their packages from the trunk with the packaging script.

    $ php release/cli-make-package.php
  1. Upload the content of release/trunk/files in the /home/pfs/project/wikindx/archives directory of the SourceForge WIKINDX Project FTP.

  2. Upload the content of release/trunk/cus in the /home/project-web/wikindx/htdocs/cus directory of the SourceForge WIKINDX Project FTP.

  3. Try the update server. Don’t forget to switch the Trunk Version flag in debug configuration.

API Manual Release

Generate the manual for the trunk and the current version and upload them on SF. The Contributing > API Manual give details about that.

   $ php release/cli-make-api-manual.php

Website Release

  1. If a recurring request has appeared since the last release, add an entry to the website FAQ on this subject.

  2. Update the requirements in Install & Upgrade > Requirements section.

  3. Mirror the content of CHANGELOG.txt file in Install & Upgrade > Release Notes section.

  4. Check the Help Topics section is up to date and no topic is missing or misnamed.

  5. Check all the pages, and correct what no longer matches the new version.

  6. Check the main SourceForge page of the project, and correct what no longer matches the new version.

  7. Generate the website for the trunk and the current version and upload them on SF. The Contributing > Website give details about that.

    $ php release/cli-make-website.php

SVN Release

During this step, it is preferable that the release manager is the only one to modify SVN.

  1. Update your working copy.
   $ svn update
  1. Check that you don’t have uncommited changes. Go back to step 1 of Code preparation and checks if you forgot something.
   $ svn status
  1. Add an entry for the release in the SVN History section of the README.txt file at the root of the repository. The revision number indicated is the revision of the last commit included in the release.

At this point the version is officially released in SVN and should no longer be changed so that the packaged code is identical. If a last minute bug is discovered in the code for example for a bug which crashes the application and must at all costs be corrected, fix the bug in trunk and start again at step 1 of Code preparation and checks.

If the correction is very fast (a few tens of minutes) you can keep the same version number because no one will have the opportunity to install from SVN.

If the correction takes too long then it is necessary to abandon the publication of the current release, to increment the version number and to make again a complete release. In the SVN history replace the Release Date of this version with the mention “unreleased”. To have absolute safety of the published code you should only use this method.

Public Release

In case you need to release an old version, use svn checkout xxx before switching on the last commit of this release. Don’t forget to switch again to HEAD after the release!

  1. Execute the packaging script from the CLI.
   $ php release/cli-make-package.php

The layout created by this script matches exactly the layout of FTP.

  1. Without overwriting files already online, upload the content of release/X.Y.Z/files in the /home/pfs/project/wikindx/ directory of the SourceForge WIKINDX Project FTP.

  2. Without overwriting files already online, upload the content of release/X.Y.Z/cus in the /home/project-web/wikindx/htdocs/cus directory of the SourceForge WIKINDX Project FTP.

  3. Update the WIKINDX TEST DRIVE website and check that nothing bad happened before publishing to directories that are not archives. If things go wrong, correct and redo the release from the begining.

  4. Remove all files and folders of the current_release FTP directory of the SourceForge WIKINDX Project FTP and upload the content of release/X.Y.Z/files/X.Y.Z instead.

  5. On the Files section of the WIKINDX SourceForge pages, go in directory X.Y.Z, display details of the wikindx_x.y.z.tar.bz2 file, select it as the default download for all systems (Link: Select all) and save.

  6. If an old A.B.C version should no longer be highlighted, remove its A.B.C folder from the SourceForge WIKINDX Project FTP. The automatic update for the A.B.C version will continue to work because it uses the copies of the archives/ folders, which have not been deleted.

Announce

  1. Post about the release on the SourceForge News section.

BugTracker update

  1. Go in “Bugs and feature requests” section of the SourceForge Bugtracker

  2. Click on “Edit Searches” menu

  3. Click on “Field Management” menu

  4. Update or create a “Found in” milestone entry for the release X.Y.Z and fill it with the same date as the SVN History. Check the “Complete” column for older versions that are no longer supported.

  5. Update or create a “Target” milestone entry for the release X.Y.Z and fill it with the same date as the SVN History. Check the “Complete” column of the current release.

  6. Save these changes.

  7. If it has not already been done, assign all the tickets processed in this release and close them. Reassign unprocessed tickets if necessary.