Coding

Development style

The development style is Trunk-Based, and done in a development branch named trunk. A Branch for release strategy is also used.

The trunk branch (for developers and testers) can be broken at any (and for a long) time and damage your database.

The stable branch is safe and intended for production use.

Release Cycle

Release types

There are several types of release:

  • Stable releases (X.Y.0): these releases contain all the new features and other changes.
  • Patch releases (X.Y.Z): these releases fix serious or security bugs for stable releases.
  • Release Candidates (X.Y.0-rcN): these releases are a pre-release of a stable release. They are used for testing and rooting out any remaining bugs.

Examples:

  • 6.8.0: a stable release.
  • 6.8.3: third patch release of 6.8.0 stable release.
  • 6.8.0-rc2: second release candidate of 6.8.0 stable release.

Only the most recent stable release receives patches.

The README.txt file at the root of SVN describes how to get the source code of a release.

Release cycle

  1. At the start of a cycle, choose the features and corrections of the next stable release: ideally, not too many and not too long to develop. 1 year really seems the maximum, 3 to 6 months more reasonable, a shorter cycle is too intensive. There is no arbitrary date set.

  2. Do the developments in trunk branch and tests on developers’ workstations.

  3. When the version is deemed ready, development is frozen.

  4. Make a public release candidate from trunk branch, indicating that it is a test preview, and deploy on the test web sites.

  5. For one week, depending on developers availability, test and correct the release candidate. If users can test the release candidate on their side, it is a great help.

  6. At the end of this period, if there have been corrections, another release candidate is made. Otherwise the current release candidate become the new stable release. This involves replacing the code of the stable branch with that of the trunk branch.

  7. During the development phase if security bugs or serious bugs are discovered that render WIKINDX unusable, result in data loss, or violate our release policy, a patch release is released from the stable branch by picking commits from the trunk branch.

Plugins for other software like Dokuwiki share the same repository but have their own development and release cycle. See the third_party_plugins folder.

Known differences between MySQL and MariaDB

  • Do not set group_concat_max_len exactly to 1073741824. This value crashes MySQL bug.

  • Do not use MariaDB’s TRUE/FALSE boolean syntax. MySQL does not implement it.

  • Do not use the Spencer syntax of the REGEXP operator. This syntax is broken since MySQL 8.0.4 Use the \b syntax instead.

  • Do not use temporary tables because MySQL and MariaDB do not have the same behavior.

  • ’CAST( bla AS INT )’ is not a syntax supported by MySQL engine.

  • Index_Type option of “SHOW CREATE TABLE” is unreliable for InnoDB due to functionality of bug #22632.

  • MySQL cannot self-update a table.

  • Using the zero value inside an auto-incremented column raise errors on SQL dump. Don’t use it. (See NO_AUTO_VALUE_ON_ZERO sqlmode).

  • MySQL doesn’t support the IF EXISTS syntax for CREATE/DROP INDEX.

History

The release cycle was first formalized with the release of 6.7.0.

From 6.8.0, patch releases are introduced to limit the consequences of long development times on the important corrections expected by users.