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.
Since version 6.7.0 the project has adopted a pre-release or Release Candidate (RC) system described below.
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.
Do the developments and tests on developers workstations.
When the version is deemed ready, development is frozen.
Make a public release candidate, indicating that it is a test preview, and deploy on the test web sites.
For a week or two, depending on developers availability, test and correct. If users can test the release candidate on their side, it is a great help.
At the end of this period, if there have been corrections, another release candidate is made. 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 :