Coding

Development style

The development style is Trunk-Based, without [ephemeral] branch.

The version system is not a branch system with long term support for each one. Only the trunk gets new features, security and bug fixes that are not backported. These developments are made available to the public at each release of a new version.

The versions are numbered for the history and semi-automatic update system of the data and the database (each change is applied between the installed version and the target version).

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

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

Release cycle

Since version 6.7.0 the project has adopted a pre-release or Release Candidate (RC) system described below.

  1. At the start of a cycle, choose the features and corrections of the next version. Not too many and not too long to write if possible. 1 year really seems the maximum, 3 to 6 months more reasonable, shorter cycle too intensive. There is no arbitrary date set.

  2. Do the developments and tests on developers workstations.

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

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

  5. For a two weeks, depending on developers availability, test and correct. 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. If there are serious fixes requiring another beta it is possible to shorten the waiting time and release the next beta. If there were no bugs discovered, or not serious enough to justify another release candidate, the official release is published, and the development cycle resumes its course.

Release candidates are named with a suffix appended to the target release name. For example :

  • 6.7.3-rc1
  • 6.7.3-rc2
  • 6.7.3-rc3

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.