about:release_and_branchs [Piwigo Wiki]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Branches and releases ======

How does the Piwigo release system work?  What is the difference between the release 1.3.1 and release 1.4.0?

===== Releases =====

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.

===== Branches with a graph =====

What about ASCII art graph of branch an releases :

  +-------+
  | trunk |
  +-------+
    |
    | 1.3.0RC1 r158 2003-09-21
    | 1.3.0RC1 r181 2003-10-05
    | 1.3.0    r205 2003-10-12
    |
    +-------- branch 1.3 ----------+
    |                              | 1.3.1    r379  2004-02-28
    |                              | 1.3.2    r448  2004-06-29
    |                              | 1.3.3    r551  2004-10-03
    | 1.4.0RC1 r683 2005-01-09     |
    |                              | 1.3.4    r713  2005-01-20
    | 1.4.0RC2 r718 2005-01-21
    | 1.4.0RC3 r741 2005-02-13
    | 1.4.0    r750 2005-03-12
    |
    +-------- branch 1.4 ----------+
    |                              | 1.4.1    r790  2005-05-14
    | 1.5.0RC1 r871 2005-09-21
    | 1.5.0RC2 r907 2005-10-22
    |
    +-------- branch 1.5 ----------+
    |                              | 1.5.0    r929  2005-11-08
    |                              | 1.5.1    r978  2005-12-10
    |                              | 1.5.2    r989  2005-12-25
    |
    +--------- branch 1.6 ---------+
  A |                              | 1.6.0RC1 r1263 2006-04-24
  L |                              | 1.6.0RC2 r1319 2006-05-23
  L |                              | 1.6.0    r1432 2006-07-04
  I |                              | 1.6.1    r1482 2006-07-18
  G |                              | 1.6.2    r1599 2006-11-09
  A | Alligator1 r1709 2007-01-10
  T | Alligator2 r1787 2007-02-07
  O | 1.7.0RC1   r1825 2007-02-15
  R | 1.7.0RC2   r1938 2007-04-06
    |
    +-------- branch 1.7 ----------+
  B |                              | 1.7.0    r1999 2007-05-05
  U |                              | 1.7.1    r2193 2008-01-24
  T |                              | 1.7.2    r2457 2008-07-24
  T | Butterfly1 r2492 2008-08-31  |
  E | Butterfly2 r2522 2008-09-12  |
  R |                              | 1.7.3    r2762 2008-09-16
  F | 2.0.0RC1   r2615 2008-09-27
  L | 2.0.0RC2   r2658 2008-10-04
  Y |
    +-------- branch 2.0 ----------+
  C |                              | 2.0.0RC3 r2732 2008-10-13
  O |                              | 2.0.0RC4 r2866 2008-11-12
  L |                              | 2.0.0    r3153 2009-02-15
  I |                              | 2.0.1    r3210 2009-03-17
  B |                              | 2.0.2    r3276 2009-05-06
  R |                              | 2.0.3    r3526 2009-07-05
  I |                              | 2.0.4    r3868 2009-09-19
    |                              | 2.0.5    r4016 2009-10-11
    |                              | 2.0.6    r4209 2009-11-05
    |                              | 2.0.7    r4533 2009-12-19
    |                              | 2.0.8    r4754 2010-01-26
    |                              | 2.0.9    r5013 2010-03-01
    | 2.1.0RC1   r5410 2010-03-27  |
    | 2.1.0RC2   r5848 2010-04-14  |
    | 2.1.0RC3   r6015 2010-04-30  |
    |                              | 2.0.10   r6117 2010-05-11
    |
    +-------- branch 2.1 ----------+
    |                              | 2.1.0    r6202 2010-05-18
    |                              | 2.1.1    r6347 2010-05-25
    |                              | 2.1.2    r6630 2010-06-29
    |                              | 2.1.3    r6914 2010-09-14
    |                              | 2.1.4    r7506 2010-10-30
    |                              | 2.1.5    r7612 2010-11-04
    | 2.2.0RC1   r8811 2011-01-20  |
    |                              | 2.1.6    r8857 2011-01-24
    | 2.2.0RC2   r9116 2011-02-08
    | 2.2.0RC3   r9373 2011-02-25
    | 2.2.0RC4   r9618 2011-03-11
    | 2.2.0      r9955 2011-04-01
    |
    +-------- branch 2.2 ----------+
    |                              | 2.2.1    r10437 2011-04-17
    | 2.3.0beta1 r11186 2011-06-01 |
    |                              | 2.2.2    r11198 2011-06-01
    |                              | 2.2.3    r11288 2011-06-10
    | 2.3.0beta2 r11591 2011-07-01 |
    |                              | 2.2.4    r11755 2011-07-15
    | 2.3.0beta3 r11847 2011-07-29 |
    |                              | 2.2.5    r12024 2011-08-31
    | 2.3.0RC1   r12040 2011-09-02 |
    | 2.3.0RC2   r12134 2011-09-12 |

===== Release numbers : x.y.z =====

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)

===== Parallel working =====

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)
  * we respect real branch names in Subversion

===== Beta, Release Candidate, Final =====

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.

Example : 1.3.0beta >> 1.3.0RC1 >> 1.3.0RC2 >> 1.3.0
Back to top
about/release_and_branchs.1316182634.txt.gz · Last modified: 2011/09/16 14:17 by mixedbredie
Sitemap Recent changes
Show page
Old revisions