Robert Ramey wrote:
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.
So what ? I recently added a new feature to the boost.python library, in a patch I committed to trunk. What if Joe Random tomorrow submits a separate patch, making use of this feature ? What, then, if the two changesets are (separately !) considered to be merged into some other branch ?
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.
Huh ?
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.
First, I'm not necessarily talking about dependencies between different libraries, I'm talking about dependencies between patches / changesets, no matter what source they are applied against. Second, the issue I'm talking about has nothing to do with whether the change is documented or not. The dependency between the changesets needs to be tracked, somehow. Third, even if something (library or not) changes in trunk, and something other is added relying on this change. That doesn't yet answer how those two changes percolate into any release branch.
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.
That's your definition of a 'sandbox' and of an 'experiment'. And even if I buy into that: Nothing prevents me from considering the whole boost trunk to be such an experiment. ;-)
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.
That's not the only concern. As lots of people have repeatedly stated on this ML: the point of a bugfix-only release is to fix bugs while fully preserving ABI and API compatibility. Regards Stefan -- ...ich hab' noch einen Koffer in Berlin...