Stefan Seefeld wrote:
If this shows up when a merge is made of a library into the release ready branch it should be considered a bug as it must be a break in an interface contract.
I fail to understand what you are saying. As far as I know, there are no 'interface contracts' on trunk. And, adding a new feature in patch A, which a subsequent patch B relies on is certainly a possibility, if not even likely.
It is not an attribute of the branch but of the library. The "interface contract" is that the library does what it's documentation says it does.
The point I'm trying to make is that, as far as I can see, there is no dependency tracking between changesets, so it may be hard to tell whether a merge of any changeset from trunk to the release branch will be self-contained, or rely on another merge being done first.
There should be no direct dependency between changesets. If there is - its a bug. Library A should depend upon, and only upon, the documented interface of Library B. If merging B into the release branch breaks library A - then either B as changed its interface so it doesn't match the documentation or A wasn't incompliance with the documentation. Either way its a bug.
Anyways, my main point remains this:
The way you treat the 'release branch' is how other projects use 'trunk' for, while what you name 'trunk' is more of a 'sandbox' elsewhere.
Nope. The trunk is where libraries are tested before being merged into the trunk. A "sandbox" would be a separate branch where experiments are conducted. For this one doesn't need all the testing on various platforms - yet. When the "experiment" is ready for that, then it gets merged into the trunk.
Only that boost doesn't have what other projects call release branches, so you are unable to do bugfix-only releases.
The release branch is almost always ready for release. If a user needs a bug fix or "hot patch" - all he has to do is download it from there. He can either download the whole thing or just the library he's interested in. Robert Ramey