• R/O
  • SSH

tortoisesvn: Commit

Commit MetaInfo

Revision4307 (tree)
Zeit2005-09-03 08:02:18

Log Message

Update release procedure with what we actually do, or what we hope to do.

Add a release FAQ which explains why we do it this way.
The FAQ is not linked to from the rest of the website yet.

Ändern Zusammenfassung


--- trunk/Release_procedure.txt (revision 4306)
+++ trunk/Release_procedure.txt (revision 4307)
@@ -1,17 +1,25 @@
1-- about a week or two before a new release, which can be initiated by
2- any dev, we create a branch from /trunk for that release
3-- the nightly builds switch from /trunk to that branch so that from this
4- time on users can test the release candidate
5-- bugs found and fixed during that time are fixed on /trunk, and
6- mentioned in a Backport.txt file on the branch
7-- the dev who fixed that bug decides himself if it should be backportet
8- or not, and if yes merges it to the release branch right away
9-- if another dev then objects to that merge (of course always with an
10- explanation why) that fix get's undone on the branch. I don't think
11- that will happen very often though.
1+TSVN releases are generally cut directly from the trunk, unless there is
2+a particular reason to do otherwise, eg. bugfix-only branch for older OS.
13-Then, on the release branch:
4+The rationale for this is described in www/release_info.html
6+- about a week before the release, an announcement is made on the
7+ mailing list, indicating the expected release date and encouraging
8+ users to download and test the nightly builds.
10+- during this period, only 'safe' changes are committed, ie. bugfixes,
11+ resource and doc updates, and trivial changes.
13+A major release (one which adds significant new features) is usually
14+preceded by a few release candidates. These are created in the same
15+way as the full release, but the requirement for 1 week's stabilisation
16+may be relaxed. Release candidates are created simply to allow more
17+widespread testing than can be achieved with the nightly builds.
18+They are announced in the same way as a full release to encourage
19+more users to take part in testing.
21+These steps are required to generate the release:
1523 - Check the latest versions of Apache, openssl, zlib, neon and of course
1624 download any newer versions available.
1725 - increment the version number in version.in file
--- trunk/www/release_faq.html (nonexistent)
+++ trunk/www/release_faq.html (revision 4307)
@@ -0,0 +1,72 @@
1+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
4+<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
6+<link rel="stylesheet" href="styles_html.css" type="text/css">
9+ <h2>TortoiseSVN Release FAQ</h2>
11+<h2>How often is TortoiseSVN released</h2>
13+<p>Normally there is a new release of TortoiseSVN every time there is
14+a new release of Subversion. This means that we are always using the
15+latest bug-fixed Subversion libraries. Occasionally, if a major bug
16+is found in TortoiseSVN, there may be an additional release to
17+fix that.</p>
19+<h2>Why are the version numbers of Subversion and TortoiseSVN different?</h2>
21+<p>Because TortoiseSVN is usually released soon after Subversion,
22+the version numbers are often the same. But they are independent projects
23+and version numbers are not always aligned.</p>
25+<h2>Does TortoiseSVN follow the same release procedure as Subversion?</h2>
27+<p>No. Releases are almost always cut from a tag taken directly from the trunk
28+rather than using a release branch. This is competely different from the
29+much more conservative approach taken by the Subversion project.</p>
31+<p>Subversion provides the access to and management of the version control
32+database. It is absolutely critical that the Subversion libraries are
33+well tested and reliable, so they adopt a very careful and controlled
34+release strategy in order to maximise data safety.</p>
36+<p>TortoiseSVN is a client which uses the Subversion libraries to do
37+all the work. If there is a bug in TortoiseSVN it may be inconvenient,
38+but it should not compromise data safety, so we do not require the
39+same stringent release procedure. This also allows for much a more
40+dynamic development process, and less administrative overhead.</p>
42+<h2>What are Major and Minor releases?</h2>
44+<p>We define a major release as one which adds significant new
45+features. Normally this happens when Subversion adds a new
46+feature, and TSVN grows some new UI to support it.</p>
48+<p>A minor release includes bugfixes and some new features,
49+but not large scale changes. There may still be a lot of
50+small changes.</p>
52+<h2>How are releases stabilised?</h2>
54+<p>We have a nightly build site which allows many people to test the
55+current trunk build. We announce each planned release about a week
56+beforehand and encourage people to test the nightly builds. During
57+this testing period, only 'safe' changes are committed to trunk.
58+This will include bugfixes and doc updates, but no new features.</p>
60+<p>Before each major release, we normally produce at least one
61+release candidate (RC) to allow for more extensive testing.
62+Release Candidates are announced in the same way as full releases
63+and allow even more people to get on with testing.</p>
65+<h2>Why don't you use a stabilising branch for releases?</h2>
67+<p>We did that at one time, but it created a lot of additional
68+work, and the stability was not noticeably better.
69+TortoiseSVN is developed by a very much smaller team than
70+Subversion, and there just aren't enough hours in the day.</p>
\ No newline at end of file
Show on old repository browser