From: Robert Ramey (ramey_at_[hidden])
Date: 2007-06-04 11:34:37
Darren Garvey wrote:
> On 03/06/07, Robert Ramey <ramey_at_[hidden]> wrote:
>> boost 1.<breaking change index>.<release number>
>> so we (soon) have 1.34.1
>> every release which doesn't break any interface would be
>> 1.34.2, 1.34.3 ....
>> (even addtion of a new library would just update the last digits).
>> the next release with a breaking change would be
> Just one minor question: what about when new libraries are added, but
> there are no breaking changes? Would that matter?
Not to me.
I find the idea of "overloading" the release number with the
information so that I would know that all 1.35.x releases have the same
interface. Having said that, I'm generally not a fan of overloading
identifiers with semantic meaning (this goes for part # etc.) as in
general it seems to eventually lead to problems. But still I
continue to hope.
Hmmm but now I think about it, adding a new library would bump
the "compatability" or interface index so My hope for the ability to
say my ap is compatible with all 1.35.x versions of boost probably
can't be supported. If 1.35.22 added a new library and I depend
upon that, I would have to say that my application is compatible
with boost versions 1.35.22 - 1.35.999 which is OK but not
really that much different then saying my app is compatible with
versions 07/04/2008 to 12/12/2008.
still I like the idea of having an "interface version number" which
would increment each time anything in the boost interface is
added to or modified. As a practical matter, I would hope
that new boost builds would come out less that 12 times / year
so we wouldn't have a HUGE number.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk