Library versioning

[Eric Evans <ee...@sym-link.com>]

Has there been any discussion of how versioning is going to work? In
particular, the C++ and C# libraries (at least) use versioning as a 
means of indicating compatibility.

For example, given libthrift.so.0.1.0, libthrift.so.0.2.0, and
libthrift.so.0.3.0, one would assume binary compatibility, (soname
libthrift.so.0). But two cli libraries versioned 0.1.0.0 and 0.2.0.0
would be treated as ABI incompatible (unless mapped otherwise).

-- 
Eric Evans
eevans@sym-link.com

Re: Library versioning

[Eric Evans <ee...@sym-link.com>]

[ David Reiss ]
> I'm pretty sure Eric is talking about the internal library version
> number used by the C++ dynamic library.  
 
Yes, exactly. Likewise, strong-naming is used to do something similar
for CLI libraries (or so I am told).

> I'm fine with pretty much any convention here.  The first thing that
> comes to mind is minor version bumps for forward incompatibility
> (adding new functions) and major version bumps for backward
> incompatibility.  However, I don't have any experience setting up the
> build to set the version (and SONAME, or whatever) properly.  If you
> do (Eric), would you mind submitting a patch?

Off the top of my head, no, but I'd be happy to look into it.

> Eric Evans wrote:
> > [ Michael Greene ]
> >> Thoughts?  We're making great strides towards getting real releases
> >> out the door, but answering some of these questions can help with
> >> future releases and ease the minds of packagers like Eric.
> > 
> > Actually, what I am most concerned with is that library versioning
> > makes sense with respect to compatibility, for each of the libraries
> > where it must.
> > 
> > So for example, if there is an soname bump on the C++ lib that it
> > corresponds with a binary incompatible library, and conversely if the
> > library changes in a backwards incompatible way, that this is
> > reflected by an so bump. I'm not that familiar with the C# stuff, but
> > my understanding is that things work similarly there.
> > 
> > Since these libraries are completely different implementations, it
> > seems dubious to me that the issues which effect compatibility will
> > always mesh. As as a result, I don't see how this versioning will be
> > able to move in lock-step with the overall project release versions.
> > 
> > I'm hoping that I'm either wrong, that this has already/is already
> > been/being addressed, or that it will be. :)

-- 
Eric Evans
eevans@sym-link.com

Re: Library versioning

[David Reiss <dr...@facebook.com>]

I'm pretty sure Eric is talking about the internal library version
number used by the C++ dynamic library.  I'm fine with pretty much
any convention here.  The first thing that comes to mind is minor
version bumps for forward incompatibility (adding new functions)
and major version bumps for backward incompatibility.  However,
I don't have any experience setting up the build to set the version
(and SONAME, or whatever) properly.  If you do (Eric), would you mind
submitting a patch?

--David

Eric Evans wrote:
> [ Michael Greene ]
>> Thoughts?  We're making great strides towards getting real releases
>> out the door, but answering some of these questions can help with
>> future releases and ease the minds of packagers like Eric.
> 
> Actually, what I am most concerned with is that library versioning
> makes sense with respect to compatibility, for each of the libraries
> where it must.
> 
> So for example, if there is an soname bump on the C++ lib that it
> corresponds with a binary incompatible library, and conversely if the
> library changes in a backwards incompatible way, that this is
> reflected by an so bump. I'm not that familiar with the C# stuff, but
> my understanding is that things work similarly there.
> 
> Since these libraries are completely different implementations, it
> seems dubious to me that the issues which effect compatibility will
> always mesh. As as a result, I don't see how this versioning will be
> able to move in lock-step with the overall project release versions.
> 
> I'm hoping that I'm either wrong, that this has already/is already
> been/being addressed, or that it will be. :)
> 

Re: Library versioning

[Eric Evans <ee...@sym-link.com>]

[ Michael Greene ]
> Thoughts?  We're making great strides towards getting real releases
> out the door, but answering some of these questions can help with
> future releases and ease the minds of packagers like Eric.

Actually, what I am most concerned with is that library versioning
makes sense with respect to compatibility, for each of the libraries
where it must.

So for example, if there is an soname bump on the C++ lib that it
corresponds with a binary incompatible library, and conversely if the
library changes in a backwards incompatible way, that this is
reflected by an so bump. I'm not that familiar with the C# stuff, but
my understanding is that things work similarly there.

Since these libraries are completely different implementations, it
seems dubious to me that the issues which effect compatibility will
always mesh. As as a result, I don't see how this versioning will be
able to move in lock-step with the overall project release versions.

I'm hoping that I'm either wrong, that this has already/is already
been/being addressed, or that it will be. :)

-- 
Eric Evans
eevans@sym-link.com

Re: Library versioning

[Michael Greene <mi...@gmail.com>]

This does match my understand, and agrees with what I know of Hadoop's
policy.  There are a few things we need to figure out as a project, I
think.

* How do we number releases?
 - We've taken an early stab at this with 0.1 and 0.2, but are we
going to have bug-fix releases with further numbers, i.e. 0.2.1?

* What do we guarantee between the versions?
 - The convention Chad submits is one I've seen before, and makes
sense to me.  If we had a release like 0.2.1, I would expect that any
code that operated in 0.2 would operate well under it.  I think
thrift-user would probably want some input here as well.

* What does 1.0 mean for us?
 - Are we working toward something?  Are versions just code
checkpoints or are there explicit milestones that we intend to hit?

A glimpse into Hadoop's versioning is illustrative:
http://wiki.apache.org/hadoop/Roadmap

Thoughts?  We're making great strides towards getting real releases
out the door, but answering some of these questions can help with
future releases and ease the minds of packagers like Eric.

Michael

On Mon, May 11, 2009 at 8:31 PM, Chad Walters
<Ch...@microsoft.com> wrote:
>
> I think the general convention is that if the major version number is 0, you
> should assume binary incompatibility for minor version changes. Once the
> major version moves to 1, then you can assume that incompatibility will be
> indicated by a major version revision.
>
> Does this match other folks' understanding?
>
> Chad
>
>
> On 5/11/09 1:32 PM, "Eric Evans" <ee...@sym-link.com> wrote:
>
>>
>> Has there been any discussion of how versioning is going to work? In
>> particular, the C++ and C# libraries (at least) use versioning as a
>> means of indicating compatibility.
>>
>> For example, given libthrift.so.0.1.0, libthrift.so.0.2.0, and
>> libthrift.so.0.3.0, one would assume binary compatibility, (soname
>> libthrift.so.0). But two cli libraries versioned 0.1.0.0 and 0.2.0.0
>> would be treated as ABI incompatible (unless mapped otherwise).
>
>

Re: Library versioning

[Chad Walters <Ch...@microsoft.com>]

I think the general convention is that if the major version number is 0, you
should assume binary incompatibility for minor version changes. Once the
major version moves to 1, then you can assume that incompatibility will be
indicated by a major version revision.

Does this match other folks' understanding?

Chad


On 5/11/09 1:32 PM, "Eric Evans" <ee...@sym-link.com> wrote:

> 
> Has there been any discussion of how versioning is going to work? In
> particular, the C++ and C# libraries (at least) use versioning as a
> means of indicating compatibility.
> 
> For example, given libthrift.so.0.1.0, libthrift.so.0.2.0, and
> libthrift.so.0.3.0, one would assume binary compatibility, (soname
> libthrift.so.0). But two cli libraries versioned 0.1.0.0 and 0.2.0.0
> would be treated as ABI incompatible (unless mapped otherwise).