Robert Ramey wrote:
Stefan Seefeld wrote:
Robert Ramey wrote:
a) designate an branch/trunk as the "Current Release". That's what I'm referring to as 'stable'. The question is what that gets created from, since it doesn't exist, yet.
Hmmm - actually it does - its the RC_1_34_1 branch. We could just designate that as the "Current Release" (or whatever you want to call it.
I've also been using the name "stable" for the "release ready" branch. And, yes, the starting point for "stable" is the current "RC_1_34_1" tag.
Effort required - 0
b) ALL development occurs on branches. I'm not sure what that means, given how subversion handles branches. The difference between 'trunk' and 'branches/something' is only in the naming.
So, given how subversion handles branches, the cost/effort of creating a branch for each developer's changes is 0
c) Testing is applied to branches as requested. I believe how test runs are triggered most efficiently depends on the usage patterns. Ideally (i.e. with infinite resources), test runs would be triggered on each change. If that isn't possible, alternative approaches can be chosen, such as 'no earlier than x minutes after a checkin', to allow developers to make multiple connected checkins in a row (though with subversion there shouldn't be any need for that, in contrast to cvs). Or, "triggered by checkins but no more frequent than once per day". Etc. (See http://buildbot.net/repos/release/docs/buildbot.html#Schedulers)
This is the missing piece. I believe it will be available in a relatively short time. The mechanism will be tests of library x will be run on branch y by any tester interested in doing this. Tests can be run whenever a tester wants to - but it will really only be necessary when a developer requests it.
Right, although as a practical matter most developers will want to test against "stable". I've been trying the following procedure for the six or eight weeks: I've got a working copy "stable" which was checked out from the RC_1_34_1 tag. I'm doing some Boost.System development on a branch "c++0x". So I've switched the components involved (.../boost/system, .../boost/cerrno.hpp, .../libs/system) to the c++0x branch. I go about testing and development as usual on my Windows machine, committing c++0x changes every time I want Chris Kohlhoff and Peter Dimov, who are helping, to be able to access work-in-process. I've also got a mini Mac and a Linux box set up with "stable" working copies checked out from RC_1_34_1. I'm running a web server on those machines (to simulate remote machines out on the Internet.) It has a "test-on-demand" web page, which fires off a CGI script written in Python that will switch a particular library to a specified branch, run bjam, upload four result files to the server, and switch the library back to the stable branch. So whenever I want to see if the code is working on the non-Windows, I sign onto the web sites, request tests be run, and have the results in a couple of minutes. Although the process needs a lot of polishing, it already works well enough to demonstrate the value of the approach. The tools involved are mainly just Subversion and bjam. The same approach would work with other testing frameworks. The bottom line is that I know that code works *before* it gets merged into the stable branch. That's the critical point; the exact way the testing is done is important operationally, but those details don't matter as far as the big picture goes.
The current testing on the "Current Release" can remain unchanged - though its usually interesting only to the release manager.
Right.
In any case, I agree to the point that there should be relatively few, but coarse grained, checkins on the 'stable' branch,
Good
Yes, agreed.
which can be backed out as a whole if any regressions occur.
I would not expect regressions of such a drastic nature that the above would be necessary.
The point of testing before actually changing the stable branch is that regressions should become very rare. --Beman