Subject: Latest revisioning plan (hopefully final)

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Oct 1998 21:45:02 +0100

If you have read the last update there is no need to
read this one. I straightened some label names, nothing
more.

Passages marked with *** have noteworthy changes since
the first 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. Also it gets a sticky label for
  the most recent beta.
  Example: 2.3.0 and 2.3_beta [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]. 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_stable          ||*2.3_beta
  2.2.0 +-------------++ 2.3.0
  [A]   |             ||[B]
        |             ||
        |             ||          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 ++<----------------
                      ||
                      ||
                      ||[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_pre_beta.

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

- We tar the 2.1.0 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].

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 30 Oct 1998 22:25:52 +0100

I had to apply a small change to the naming scheme:
CVS requires tagnames to begin with a letter and have
no '.' inside, so the suffix comes first now and dots
are replaced with underscores.

Example: 2.1_pre_beta -> pre_beta_2_1

---

From: [email-masked] (Paul D. Smith)
Date: 30 Oct 1998 16:52:52 -0500

%% Dominik Vogt <[email-masked]> writes:

  dv> If you have read the last update there is no need to
  dv> read this one. I straightened some label names, nothing
  dv> more.

  dv> ***
  dv> - The main trunk *always* holds the current beta version
  dv>   and *nothing* else.
    ...
  dv> ***
  dv> - The alpha branch is the one in which the development
  dv>   actually takes place.

Hi Dominik; it seemed to me from your previous mail that you had changed
your mind about having two branches here, and were just going to have
one (plus the stable branch, if necessary, of course).

Here's the picture you drew in a followup, that I liked:

  dv>                    main branch = beta branch
  dv>                         |
  dv>   stable branch         |
  dv>        2.2 +------------+2.3.0
  dv>            |            |
  dv>            |            |
  dv>           ...          ...
  dv>            |            |
  dv>           end           |
  dv>                         |
  dv>                         |
  dv>        2.4 +------------+2.5.0
  dv>            |            |
  dv>            |            |
  dv>           ...          ...

I guess I would draw it _slightly_ differently, but mostly it's just
cosmetic:

                    main branch
                         |
                         |2.1.x
                         |
   stable branch         |
            +------------+2.2.0
            |            |
       2.2.1|            |
            |            |2.3.0
           ...          ...
            |            |
           end           |
                         |2.3.x
                         |
            +------------+2.4.0
            |            |
       2.4.1|            |2.5.0
            |            |
           ...          ...

In this scenario, there's no "alpha" vs. "beta" branch.  Development
proceeds along the main branch.  At some point in that development
cycle, the release maintainer decides the current code is "stable
enough" and labels a beta release.  Development continues.  At some
point a stable release is made, and that's labeled (again on the main
branch).  Then if stable fixes need to be generated later (2.2.1, etc.)
the branch is created then, for those changes.

I think the extra "alpha" branch is added confusion for the purposes of
fvwm.  I agree that in a traditional SCM process you'd want something
like that, probably, but here I think it's unnecessary.

All the other net-centered open development processes I've seen just do
something like the above, plus perhaps some "major feature" branches
created by individuals.

This will work fine _if_ the people checking code into the tree are
responsible... since that's true (or they wouldn't have been given the
keys to the tree) I think we can save ourselves some headache and
merging by not bothering with the alpha branch.

Before the source is in "beta", usually it's a free-for-all.  People are
checking in as they find bugs/make fixes.  The code at the leaf of the
main CVS trunk might not run right or even compile from hour to hour,
but we're all professionals and I'm sure any breaks would be few and
rapidly corrected.

Once the source goes to beta things slow down.  I've seen groups do this
basically two ways: in the Perl world there are so many people
generating fixes that the pumpking holds the only write-keys to the
mainline branch.  Everyone sends all bugfixes as patches to him/her and
he/she approves and applies them or rejects them until the next release.

In other groups, the developers are tight-knit enough to allow everyone
to continue to generate fixes even during beta; they all know only
beta-type changes should go in.

For simplicity I think the "alpha" branch isn't required and people just
submit changes to the development branch directly, even during beta.
The only reason I can think of for an "alpha" branch is if you want
people to be able to start work on the _next_ (post-stable) version
before the previous stable version is available, and they need somewhere
to checkin.  I think most people can wait (hopefully our beta cycles
won't be too long--another advantage of only one beta/developer branch
is it gives people more incentive to use and test the beta changes :).

My $0.02.  Also, I guess I'd like to see us start with the simplest
process and if it doesn't work we can add to it, and hopefully we'll
have a better idea of exactly what we need at that point.

PS. Note that while it may seem like there's lots of development going
    on right now, I suspect it has more to do with the fact that a
    release with new features hasn't come out for a while and there's a
    logjam.  Once the jam is cleared I think development will reduce to
    a level where lots of concurrent development branches aren't really
    needed to keep things well-structured.

PPS. I suppose ultimately it's up to the release maintainer, how they
     want to handle it... if they would rather everyone made fixes to an
     alpha branch and then they'd merge to the beta, well, that's how
     it'll happen :)

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
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].

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 31 Oct 1998 13:53:11 +0100

I'm not sure anymore if the separate alpha branch is helpful,
but first idea was that having the alpha branch allowed
feature branches to be merged with the beta more easily,
but as I have dropped this idea the alpha may not be needed
anymore.

I just thought that having separate alpha and beta branches
makes it easier to define and understand what/where the
current betas are, and I still think it a good idea.

Bye

Domini