A release is a kind of snapshot at a precise instant. Release 1.3.1 will never be modified, if needed, a release 1.3.2 will appear. The snapshot is taken on a branch, release 1.3.1 is a snapshot taken on branch 1.3. A branch evolves : improvement and bug fixing. But a branch does not move considering its features : there will be no additionnal features in release 1.3.3 than in release 1.3.0, only code improvement, bug fixing and so on.

One day, PhpWebGallery dev team will propose release 2.0.0, it will mean a complete change in PhpWebGallery such as a complete recoding from scratch with an object oriented approach for example.

What about ASCII art graph of branch an releases :

             +------------+
             | branch BSF |
             +------------+
                    |
                    |     +------------+
                    |     | branch 1.3 |
          1.3RC1 => |     +------------+
          1.3RC2 => |           |
                    +-----------+
                    |           | <= 1.3.0
                    |           |
                    |           |
                    |           | <= 1.3.1
                    |           |
                    |           |
                    |           | <= 1.3.2
                    |           |
                    |           |
                    |           |
                    |           |
                    |           |
                    |           | <= 1.3.3
                    |           | <= 1.3.4
BSF_200411201925 => |           
       ...          |
BSF_200412282015 => |
                    |     +------------+
        1.4.0RC1 => |     | branch 1.4 |
        1.4.0RC2 => |     +------------+
        1.4.0RC3 => |           |
                    +-----------+
                    |           | <= 1.4.0
                    |           |
                    |           | <= 1.4.1
                    |           |
                    |           |
                    |           | <= 1.4.2
BSF_200503101005 => |           
       ...          |
BSF_200503150635 => |

A release name is always composed of 3 numbers, if the last one is omitted, let's consider it's zero : release 1.3 is in fact release 1.3.0.

• x : the major release number, 1 since the beginning and for some time I think
• y : minor release number, additionnal (or removed) features between 2 minor release number
• z : correction number, 0 when ommited. No new features between 2 correction number, 'only bug correction', differences between 1.2 and 1.2.1 are really minor but sometimes very important (security bug correction implied release 1.2.1)

The main advantage of branch versionning is that PhpWebGallery dev team can still create new fixing releases on an old branch even if a new branch has been av ailable. For example, if you find some bugs in release 1.3.2, PhpWebGallery dev team will certainly fix bugs for a release called 1.3.3 even if release 1.4.0 has already bee out for months.

There are two kinds of branchs in PhpWebGallery development model : stable branches and development branches. There is currently only one development branch, nammed BSF as Best So Far. From this development branch, starts stable branches such as branch 1.3 or branch 1.4.

Since August 2004, PhpWebGallery projects proposes development snashopt builds. They are created when a new feature or bug correction is available. Development team decides when to create builds. Builds are mainly created on BSF branch. Builds name contains the name of the branch and the datetime of build creation.

The purpose of those builds is to let advanced users to test very new features, even buggy… Testers can give there feelings about the build, report bugs, make suggestion for improvements.

When preparing a release, it has to be tested and qualified. PhpWebGallery development team work as follows :

1. release x.y.zbeta is first available. This release is designed for test by most impatient users. It is obvious for the dev team that this release may contain many bugs. The purpose is to list them all to prepare the release candidates…
2. release x.y.zRCn (n goes from 1 to… you can't know how far it can go…). Once many bugs have been corrected from the list made in release x.y.zbeta, dev team proposes a Release Candidate 1. Testers give the list of found bugs and after a (short) while, dev team proposes RC2. And so on.
3. release x.y.z (the final one) must be exactly the same than the last Release Candidate, without any known bug.

Example : 1.3.0beta » 1.3.0RC1 » 1.3.0RC2 » 1.3.0