Release process (was release 3.2.1)

[Robert T. Short]

Soren Hauberg wrote:

fre, 10 07 2009 kl. 15:06 -0700, skrev Robert T. Short:
  

So are you suggesting that we don't have a stable branch?  I guess
that is one way!  It certainly works for the developer community but
not for the general user community.  Is it not a goal to provide a
solid package for non-developer users?
    

Not quite what I meant. Right now we have two branches:

  * The 3.2.x stable branch. This is the one most users are on.
  * The 3.3.x development branch. This is the one developers are mostly
    using; it's the 'fun' branch.

Some time before 3.4.0 is to be released then we will have the following
branches (assuming we use the same approach as we do now)

  * The 3.2.x stable branch.
  * The 3.4.0-beta branch, where only bog fixes are allowed.
  * The 3.5.x development branch, where the fun stuff happens.

My suggestion was not to make the 3.5.x branch. This will probably slow
down development somewhat, but it will ensure that people on the
development branch serves as beta testers. This was essentially how
things were done before the switch to Mercurial.

Soren



  

OK.  This makes more sense to me.

The problem I am having is calling the 3.2.x branch stable.  It isn't stable.  After it has existed for a while it should become stable, but it isn't stable yet.

Here is my view of the current release process:

- We create a snapshot of the development sources.
- We apply patches for a few days
- We call the release stable.

The problem is that there always seem to be dozens of patches in those few days in the second step, so the release is NOT stable.  There was some discussion of beta testers, but what is occurring is that we never even get out of ALPHA test before we call it stable.  Here is what I would propose.

- Clearly define what the release criteria are.  I think Jaroslav plans this
  to be simply every two months.  I think that is too fast, but if that is the
  criteria, stick by it.
- Freeze the current stable version forever - no more bug fixes, patches, etc.
- Snapshot the development branch into the "stable" source tree.  It isn't
  stable yet of course, but the objective is to stabilize it.  For now it is
  a "testing" or "alpha" version.
- Apply bug fixes (no new features) for several weeks - until the bug fixes
  from the developer community slow down to a fairly low rate.  This is
  *alpha* testing.

  I would strongly encourage ALL developers to install the testing version
  during this period.  Like Soren and probably many of the rest of you, I
  tend to install a fairly recent tip for my own work, but there is little
  penalty to using this version for a few weeks.

  During this time, do your work with it.  Run scripts, functions, etc., but
  all you need to do is make sure *your* stuff works.  I think this will
  actually get a lot of code coverage. 

-  When the bug rate drops to a reasonable level, release the testing version
   to the greater user community as a beta version.  The developers should
   probably move on to the tip at this point so the tip is getting the some
   scrutiny.

Note that with this model there are only two active branches at any time, which is what Soren was suggesting, I think.  Also, the only significant difference between this model and the current model is that we wait until the bugs dwindle before releasing it to the public.

I agree that more tests are essential, but I also agree with Soren that tests are not enough.  People have to use the software to do their jobs.  If we do this, the only extra effort involved is making sure you are using the "testing" version rather than the tip.

Bob