Subject: Update of revisioning plan

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Oct 1998 18:11:38 +0100

Passages marked with *** have noteworthy changes since
the previous draft. Probably it is best to have a look
at the picture first.

-----------------------------------------------------------

(In this example I use some future revisions: 2.2.x for
the next stable and 2.3.x for the beta releases; [X]
denotes a reference to the picture below).

Versioning/development takes place in three different
branches in CVS:

***
- The main trunk *always* holds the current beta version
  and *nothing* else. It is labeled with an odd number in
  the second component.
  Example: 2.3.0 [B]

***
- The stable branch holds *always* the latest stable
  release and *nothing* else. The second component of
  a stable release is an even number. It is split off
  from the main branch as soon as a new major beta
  number is implemented and is one version number
  behind it. The stable branch is a dead end. Finally
  the main trunk will replace the old stable branch.
  Example: 2.2.0 [A]

***
- The alpha branch is the one in which the development
  actually takes place. It is split off from the beta
  immediately after a new major beta release is
  created and gets the labels <x.y>_alpha_start, the
  sticky label <x.y>_alpha and similar start label with
  an additional '.0'
  Example: 2.3_alpha, 2.3_alpha_start and
           2.3.0_alpha_start [C].

The main and stable branch are always tared and published
on the web. They advance in the third component during
a development cycle.

The stable branch gets bugfixes only, new features
usually go into the main (beta) trunk [D].

The beta branch is synchronized with the alpha branch for
new beta versions regularly, but the alpha branch is not
closed now [E].

***
When the next major stable release is pending, the alpha
branch is closed and finally merged into the beta branch
[F]. At this moment the beta branch is labeled <x.y>_beta
(sticky). During a beta tesing phase no development is
done at all [G]. Only bugfixes are integrated into the
beta.

***
When the beta is stable the main trunk gets a new second
component number, the third number is reset to zero, a
new stable branch is split off [H] and the cycle starts
again.

Separate development branches:
------------------------------
***
Development for larger changes takes place in separate
branches split off from the current beta or alpha branch
[I]. They may take some time and will finally be closed
and merged into the current alpha branch [J].

You might object that not merging the feature branch
with the alpha branch may cause confusion. This is
true, but the win is that the developer of the
feature branch has less work when trying to merge it.
Merging small changes is usually easier than merging
a large patch, and this simplifies it somewhat.

Now the figure:
---------------
+ in the tree denotes a new label
* before a name denotes a sticky label

               development branch
                = main trunk
                      ||
 stable branch        ||
  2.2   +-------------++ 2.3.0
  2.2.0 |             ||[B]
  [A]   |             ||
        |             ||          2.3_alpha_start
        |             ||         *2.3_alpha             feature_A_start
        |             ||          2.3.0_alpha_start    *feature_A
        |             ||----------------+---------------------+
  2.2.1 +             ||             [C]|                  [I]|
        |             ||                |                     |
  2.2.2 +             ||                |                     |
     [D]|             ||                |                     |
        |       2.3.1 ++<---------------| 2.3.1_alpha_start   |
        |             ||[E]             |                     |
        |             ||                |                     |
        |             ||                |                     |
  2.2.3 +             ||                |                     |
        |             ||                |                     |
        |             ||                |<---------------------
        |             ||                |[J]
        |             ||                |

       ...           ....              ...

        |             ||                |
        |             ||                |
        |             ||                |
  2.3.x +             ||[F]             |
       ---      2.3.y ++<----------------
            *2.3_beta ||
                      ||
                      ||[G]
              Beta tests and bugfixes
                      ||
                      ||
  2.4.0 +<------------++2.5.0
  [H]   |             ||
        |             ||
        |             ||
   (and again from the start)

-----------------------------------------------------------------

What will we do to switch to this scheme:
-----------------------------------------

***
- There will be no 2.0.47 or 2.0.48. This line of
  numbering versions is dead forever.

- The current animicons_menupos branch is closed and
  merged into the main trunk.

- The beta branch is opened according to above plan
  and labeled 2.1.0.

- Steve merges the changes for autoconf into the 2.1.0
  beta branch and we relabel it as 2.1.1.

- We tar the 2.1.1 beta branch, put it on the web and
  announce it very soon.

- The alpha branch is opened and labeled.

- Other changes go into the alpha branch (like the myriad
  of smaller patches or Germans patches). New beta versions
  are packaged, announced and put on the web.

- When we have implemented the changes we want, the
  alpha branch is closed and official beta testing
  commences.

***
- When the beta is stable enough, the beta branch is
  labeled 2.3.0 and the 2.2.0 stable branch is split off
  and 'shipped'.

----------------------------------------------------------

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].