[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Release management policy fundamentals

From: Nick Patavalis <npat_at_efault.net>
Date: 2005-01-12 22:10:52 CET

On 2005-01-12, Ben Collins-Sussman <sussman@collab.net> wrote:
>
> The HACKING file in subversion's source tree describes our own release
> process.
>
> Also, last weekend I documented this pattern in the svn book:
>
> http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.4
>

Thanks for the pointer. This is very interesting indeed. Some
comments:

  Teams continue to work in parallel. One team begins rigorous testing
  of the release branch, while another team continues new work (say,
  for version 2.0) on /trunk. If bugs are discovered in either
  location, fixes are ported back and forth as necessary. At some
  point, however, even that process stops. The branch is "frozen" for
  final testing right before a release.

  [ ... ]

  The branch is maintained over time. While work continues on /trunk
  for version 2.0, bugfixes continue to be ported from /trunk to
  /branches/1.0. When enough bugfixes have accumulated, management may
  decide to do a 1.0.1 release

I assume that during the "stabilization period", after branches/1.0 is
created, and before the software is released, most developers work on
the 1.0 branch, instead of on the trunk. After the first release is
tagged (tags/1.0.0 is created) and shipped, developers switch-back
working on the trunk. In a trivial case, when no post-1.0.0 features
are contemplated while getting ready for the first release (something
thay may not be unreasonable for small development team), the 1.0
branch and the 1.0.0 trunk are created "simultaneously". In this case
the branch is still created (instead of copying directly from trunk to
tags/1.0.0) only to maintain "symmetry" by validating the assertion
that "all 1.0.x release-tags are snapshots of the 1.0 branch".

The second quoted paragraph seems to insinuate that once the first 1.0
release is out (once 1.0.0 is out), no one ever works directly on
branches/1.0 again. Only modifications from trunk are merged in it. I
would think though that, occasionally, some work may be committed
directly on the branch (not merged from the trunk). For example,
fixing a serious bug that is no longer applicable to the diverged
trunk.

  The branch is maintained over time. While work continues on /trunk
  for version 2.0, bugfixes continue to be ported from /trunk to
  /branches/1.0. When enough bugfixes have accumulated, management may
  decide to do a 1.0.1 release: /branches/1.0 is copied to
  /tags/1.0.1, and the tag is packaged and released.

I assume that this---as well as other similar phrases above---should
read: "The branch is maintained over time. While work continues on
/trunk for version *1.1*, bugfixes continue...". Otherwise I fail to
see the purpose of the middle zero in the release numbers.

Regards
/npat

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 12 22:13:25 2005

This is an archived mail posted to the Subversion Users mailing list.