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.
The process is valid for the trunk branch as for the stable branch. However, if a major element such as the database schema, internal version, component compatibility versions or minimum accepted PHP/MySQL version changes during a maintenance release then these changes must be compatible with the version in development.
Before using the delivery tools, make sure you have configured them for the PRODUCTION environment.
If not, copy the file release/cnf-release.inc.php.dist to release/cnf-release.inc.php and change values.
In the event of a change in structure or the addition of a third-party library in a plugin, update:
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
Check the release number in WIKINDX_PUBLIC_VERSION and the changelog.
Change WIKINDX_RELEASE_DATE to the current date and WIKINDX_COPYRIGHT_YEAR to the current year.
Check the internal version number in WIKINDX_INTERNAL_VERSION. Increment it by one (and one only) if a core upgrade is needed.
If the internal version has changed since the last public release, then add the highest of them to WIKINDX_INTERNAL_PUBLIC_VERSION_MAPPING.
Check that WIKINDX_COMPONENTS_COMPATIBLE_VERSION[“plugin”] and $wikindxVersion in compatible plugins have the same value.
Check that the core upgrade stage for this version is complete and functional: database, constants, variables, files, folders, messages, version numbers.
Check that the plugins upgrade for this version is complete and functional: database, constants, variables, files, folders, messages, version numbers.
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.
Check if a code change has changed PHP extensions compatibility.
Update \UTILS\listCoreMandatoryPHPExtensions() and
\UTILS\listCoreOptionalPHPExtensions() functions.
Check that the changelog of the core is complete.
Check that the changelog of each component is complete.
Update component.json file of components and check their integrity in the admin components panel.
Update the db schema of the Repair Kit (only if the db schema have been changed for this release).
$ php src/cli-dump-repairkit-schema.php
$ php src/cli-make-translations.php
On the translation deadline, download the translated files from Transifex to SVN. Don’t use files for ’en’ locale. This is the reference language.
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 src/cli-sign-components.php
Commit them to SVN. Step 20 to 23 are optional. In case of error, change the code and restart to step 18.
When the components are up to date, build their packages from the trunk with the packaging script.
$ php release/cli-make-package.php
Upload the content of build/trunk/packages in the
/home/pfs/project/wikindx/archives directory of the SourceForge WIKINDX
Project FTP.
Upload the content of build/trunk/cus in the
/home/project-web/wikindx/htdocs/cus directory of the SourceForge
WIKINDX Project FTP.
Try the update server. Don’t forget to switch the Trunk Version flag in debug configuration.
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
If a recurring request has appeared since the last release, add an entry to the website FAQ on this subject.
Update the requirements in Install & Upgrade > Requirements section.
Mirror the content of CHANGELOG.txt file in Install & Upgrade > Release Notes section.
Check the Help Topics section is up to date and no topic is missing or misnamed.
Check all the pages, and correct what no longer matches the new version.
Check the main SourceForge page of the project, and correct what no longer matches the new version.
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
During this step, it is preferable that the release manager is the only one to modify SVN.
$ svn update
$ svn status
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.
If it is a release from the trunk branch, replace the content of stable branch with trunk_ branch content (do not try to merge or copy).
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.
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!
$ php release/cli-make-package.php
The layout created by this script matches exactly the layout of FTP.
Without overwriting files already online, upload the content of
build/packages/X.Y.Z in the /home/pfs/project/wikindx/ directory
of the SourceForge WIKINDX Project FTP.
Without overwriting files already online, upload the content of
build/X.Y.Z/cus in the /home/project-web/wikindx/htdocs/cus directory
of the SourceForge WIKINDX Project FTP.
Copy CUS files in SVN CUS database (cus/components and cus/core folders). WARNING: the source code archive of a component will have a unique signature at each generation.
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.
Remove all files and folders of the current_release FTP directory
of the SourceForge WIKINDX Project FTP and upload the content of
build/X.Y.Z/packages/X.Y.Z instead.
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.
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.
Go in “Bugs and feature requests” section of the SourceForge Bugtracker
Click on “Edit Searches” menu
Click on “Field Management” menu
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.
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.
Save these changes.
If it has not already been done, assign all the tickets processed in this release and close them. Reassign unprocessed tickets if necessary.
The release is the right time to do a general backup of the project. Visit the Project backup page.