Robert Ramey wrote:
Stefan Seefeld wrote:
The expectation is that most people will merge to the release branch only periodically, when there are a number of release-ready changes pending.
As usual, this may get quite complex if changesets are interdependent. I.e., it may be that one patch that went into trunk only works because of another patch in trunk, but would fail in release without the other there applied first.
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. 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. 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. Only that boost doesn't have what other projects call release branches, so you are unable to do bugfix-only releases. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...