As to Nick Patavalis' last comment about version numbers in the SVN book, I
have a few comments as to how I read it...
In VB6 version numbering was described as <major revision>.<minor
revision>.<build number>. In practice, I have seen a four-part number
frequently used, such as 6.0.2900.2180 (Explorer.exe in MS Windows XP SP2).
Presumably this follows the structure of <major revision>.<minor
revision>.<update/patch>.<build number>. The SVN book could have been using
the format <major revision>.<minor revision>.<update/patch> and dropping the
build number (also common).
To the gallery: Is it standard to release a patch to a 1.0 product as 1.0.1
or as 1.1? Do folks know of common practice definitions/references for
version numbering? How do Alpha/Beta/Gamma releases fit in? (sorry if
these are noobish questions...)
I would lean towards to former (patch 1 to 1.0 is 1.0.1, not 1.1), so that
the following progression would make sense:
1.0.0 Final release for version 1.0
1.0.1 Patch 1 to version 1.0
1.0.2 Patch 2 to version 1.0
1.1.0 Final release version 1.1 (minor new features since 1.0)
1.1.1 Patch 1 to version 1.1
2.0.0 Final release for version 2.0 (major new features/design since 1.0)
Work could progress in the 1.0.1 branch while also progressing in EITHER a
1.1 or a 2.0 branch, depending on how major the new features were considered
to be. Thus Nick P AND the book could be describing valid scenarios.
Good discussion BTW! Very helpful to me as I design a large and complex
Subversion server and associated policies for the first time.
Nick Seigal
-----Original Message-----
From: news [mailto:news@sea.gmane.org] On Behalf Of Nick Patavalis
Sent: Wednesday, January 12, 2005 1:11 PM
To: users@subversion.tigris.org
Subject: Re: Release management policy fundamentals
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 13 01:14:20 2005