A release is a kind of snapshot of the code 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 therefore release 1.3.1 is a snapshot taken on branch 1.3. A branch evolves through improvement and bug fixing. But a branch does not move considering its features: there will be no additional features in release 1.3.3 than in release 1.3.0, only code improvement, bug fixing and so on.
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, additional (or removed) features between 2 minor release number
z : correction number, 0 when omited. 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 Piwigo development team can still create new fixing releases on an old branch even if a new branch has been available. For example, if you find some bugs in release 1.3.2, Piwigo development 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 Piwigo development model : stable branches and a development branch. The development branch is called “trunk”. From trunk, we create stable branches such as branch 1.3, 1.4 or 2.0.
To make it more simple for developers, the trunk gets a new specific codename each time a stable branch is created. Examples:
trunk gets the codename “Alligator” once stable branch 1.6 was created, “Alligator” became branch 1.7
trunk gets the codename “Butterfly” once stable branch 1.7 was created, “Butterfly” became branch 2.0
trunk gets the codename “Colibri” once stable branch 2.0 was created, “Colibri” will become branch ?.?
The advantages of using a codename on trunk instead of the futur branch name are:
we don't always know in advance what will be the name of the future stable branch (during several months, we didn't know “Butterfly” would become branch 2.0)
When preparing a release, it has to be tested and qualified. Piwigo development team works as follows:
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…
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.
release x.y.z (the final one) must be exactly the same than the last Release Candidate, without any known bug.