Darren Garvey wrote:
On 03/06/07, Robert Ramey <ramey@rrsd.com> wrote:
<snip> 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 1.35.0
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 "compatibility" 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. Robert Ramey