Re: [boost] [1.37.0] branches/release open for merges

From: Robert Ramey (ramey_at_[hidden])
Date: 2008-08-21 17:03:02

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