Stefan Seefeld wrote:
Robert Ramey wrote:
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 ?
here's the sequence: a) Joe tests his stuff against the latest release and its working: b) you add new feature to the python library and upload it into the trunk and test it. c) After about week of looking at the test results, you're happy with it and now merge it into the release branch. (inlcluding the updated documentation describing the new faciity). d) Joe looks at your new stuff in the release branch and new documentation and decides that its something he want's to use and alters his code accordingly. No problem. They only way there could be a problem is if Joe were to start using the new feature before its merged into the release - which a) is pretty unlikely as he doesn't see it until its merger, and b) is his problem any as he takes a chance on relying on a new interface which is still being tested.
What, then, if the two changesets are (separately !) considered to be merged into some other branch ?
I don't know what other branches. Here is the drill, change sets are merged into the trunk to be tested, then - if testing suggests it a good idea - changes are merged from trunk to release.
There should be no direct dependency between changesets. If there is - its a bug.
Huh ?
yep - its a bug it means that
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.
If patches should only depend upon previous patches - how could it be otherwise. Since all patches are merged into the releae branch in order, the the release is always working. I can't see how this can be a problem.
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.
Nope. If all libraries are coded against a documented interface, and the library implements that interface as documented, then there is no need to track anything else.
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.
Here's the answer. library A changes in the trunk. Since the changes are "brand new" nothing else can depend upon them. Once they are merged into the release, everyone can depend upon them with out problem. and those dependent libraries will be enhanced, tested and merged into the release when the author feels they are ready. There is no conflict nor ambiguity. ]>> 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'.
correct, though I don't know how it would differ much from anyone elses.
And even if I buy into that: Nothing prevents me from considering the whole boost trunk to be such an experiment. ;-)
Actually it IS an experiment. Its where code is uploaded in order to be tested in the environments which testers want to see boost support. That's exactly why it is not and can never be "release ready"
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.
I don't know about the current state of things. But if there exists a simple, reliable, automatic and convenient method for creating a release tarball (as there should be), Then just invoke to create a "point release" every time there is library merge into the release ready branch. This is the central requirement for "point release" or "hot fix"' API compatiblity is the library correctly implementing its documented interface. ABI compatibility can only be guarenteed by the user rebuilding the "point release". Neither are related to the procedure for delivering "point release" or "hot fixes" Robert Ramey