We now have a number of changes proposed for 1.0 -- mostly API stuff,
but I'm sure there will be bugfixes too. We need a process for
deciding which ones get included. Below is a proposed patch to
HACKING about this. Any objections if I commit this?
Its main goals are:
* To gather all the proposed changes in one place, so we can easily
compare them with each other, and get a sense of how much total
destabilization we're looking at. It would be impossible to make
good decisions without such an overview.
* To provide a canonical place to record votes, so we don't have to
comb mailing list threads.
* To clearly separate the question of "Should this get fixed on
trunk?" from "Should the fix go into 1.0?". We'll be answering
the first question "Yes" much more often than the second.
Btw, this is unrelated to the version numbering discussion going on in
another thread. Sorry to have two process threads running at once,
but we need to figure this stuff out now so we won't have to go
through it all again in the future :-).
Also, note that we're creating the "1.0-stabilization" branch on
Friday, from the 0.35.0 tag. Thus, changes made on trunk since r7994
will *not* be in 1.0 unless merged to its branch -- after going
through the process below, or whatever process we come up with, of
course. I've mentioned that before, but wasn't sure whether everyone
heard it :-).
-Karl
Index: HACKING
===================================================================
--- HACKING (revision 8002)
+++ HACKING (working copy)
@@ -36,6 +36,7 @@
* How to release a distribution tarball
* Release numbering
* Compatibility
+ * Stabilizing a release branch
Participating in the community
@@ -1417,3 +1418,57 @@
This mechanism is a last resort, to be used when capability
keywords would be too hard to manage.
+
+
+Stabilizing a release branch
+============================
+
+[For clarity, this section is written specifically for the 1.0
+release. The same principles apply to future releases; it may be
+appropriate to generalize this section after 1.0 is out.]
+
+First, we create a "1.0-stabilization" branch based on the last
+interim release:
+
+ $ svn cp http://svn.collab.net/repos/svn/tags/0.35.0 \
+ http://svn.collab.net/repos/svn/branches/1.0-stabilization
+
+Trunk development can continue normally, since changes on trunk do not
+affect the 1.0 release unless explicitly merged in. However, we try
+to avoid major new initiatives on trunk while we're stabilizing 1.0.
+As developers must still review trunk commits, the more we can reduce
+that distraction, the more attention we can devote to the release
+line.
+
+Certain trunk changes are desirable: those that are meant to be merged
+into the 1.0-stabilization branch. The preferred way to get a change
+into the release is to make the change on trunk, then port it over.
+This is partly to ensure that the change will be in future Subversions
+as well as in the upcoming release; but also, it gives the developers
+something concrete to vote on for inclusion in the release line.
+
+A change needs three +1 votes and no vetoes from full committers to go
+into the 1.0-stablization branch. We use the STATUS file in the top
+level of the release branch for recording votes. Each item is a short
+identifying string (a revision number, an issue number, etc), a brief
+description of the change, followed by the votes. For example:
+
+ * r98765
+ Make the svn_read_user_mind() function accept NULL input.
+ See mailing list thread http://...
+
+ Votes for merging into 1.0:
+ +1 ghudson
+ +1 bliss
+
+We don't use the issue tracker for the voting, because the question of
+whether something should be fixed is separate from the question of
+whether the fix should go into 1.0. Issues are about recording the
+existence of the bug, feature request, whatever, and getting the
+change into the main development line of Subversion. The STATUS file
+is only about whether that particular change should go into the
+release -- which is why the STATUS file for a release lives on its
+branch, not on the trunk.
+
+The STATUS file is not the place for discussion; use the dev mailing
+list for that, and have the STATUS file point to the thread, instead.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 15 19:36:11 2003