I answered my own questions about version numbering standards and how to
incorporate alpha/beta/gamma(release candidate) releases -- at least from a
Subversion/Apache standpoint -- after a brief look at the svn HACKING
file...
[Starting in http://svn.collab.net/repos/svn/trunk/HACKING...]
Subversion uses "MAJOR.MINOR.PATCH" release numbers, with the same
guidelines as APR (see http://apr.apache.org/versioning.html), plus a
few extensions...
[...then from http://apr.apache.org/versioning.html...]
Versions are denoted using a standard triplet of integers:
MAJOR.MINOR.PATCH. The basic intent is that MAJOR versions are
incompatible, large-scale upgrades of the API. MINOR versions retain
source and binary compatibility with older minor versions, and changes
in the PATCH level are perfectly compatible, forwards and backwards
[and are purely bug-fixes, e.g. changes to implementations/content, not
interfaces/structure].
[...and back to the HACKING file]
Subversion does not use the "even==stable, odd==unstable" convention;
any unqualified triplet indicates a stable release:
1.0.1 --> first stable patch release of 1.0
1.1.0 --> next stable minor release of 1.x after 1.0.x
1.1.1 --> first stable patch release of 1.1.x
1.1.2 --> second stable patch release of 1.1.x
1.2.0 --> next stable minor release after that
The order of releases is semi-nonlinear -- a 1.0.3 *might* come out
after a 1.1.0. But it's only "semi"-nonlinear because eventually we
declare a patch line defunct and tell people to upgrade to the next
minor release, so over the long run the numbering is basically linear.
Non-stable releases are qualified with "alphaN" or "betaN" suffixes,
and release candidates with "-rcN". For example, the prereleases
leading to 1.3.7 might look like this:
subversion-1.3.7-rc1.tar.gz
subversion-1.3.7-rc2.tar.gz
subversion-1.3.7-rc3.tar.gz
subversion-1.3.7.tar.gz
Still welcoming other references/resources.
Regards,
Nick Seigal
-----Original Message-----
From: Nick Seigal [mailto:nickseigal@iinet.com]
Sent: Wednesday, January 12, 2005 4:12 PM
To: 'Nick Patavalis'; 'users@subversion.tigris.org'
Subject: RE: Release management policy fundamentals
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 02:39:36 2005