Okay, then I need to learn how to do it "properly" :(

The versioning is something that can be changed/fixed. Is the *Rest* right?

On Thu, Sep 23, 2010 at 3:57 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Thu, 23 Sep 2010, Hendrik Visage wrote:
>
>> I've been having troubles with 7.19 vs 7.21 etc. in tests w.r.t. the C++
>> wrappers... and me needing certain functionality that were not in the older
>> versions, and thus the reason I wanted to have those extra versions when
>> using these new features... and some where I had troubles with a version
>> linked to the older and I only have the later version available.
>
> Well, there are many aspects to this.
>
> Version numbers don't imply functionality at all, they're just visuals that
> are mostly for human consumptions. We have soname and ABI to maintain binary
> compatibility and functionality for applications. Our ABI document describes
> our view on that: http://github.com/bagder/curl/blob/master/docs/libcurl/ABI
>
> Later versions may support more stuff than older versions, yes. If you write
> your app correctly you should be able do downgrade the binary library and
> fail gracefully for the missing stuff.
>
> To me, it sounds like you're having a go at your own solution to a problem
> we already have a generic solution to and that's generally not a good idea.
> The better idea is to make sure we all work correctly and we have the same
> rules apply all over for all platforms we can run and function on.
>
>> The A/B vs. Release-$VERSION debate: I think that could be an "unwritten
>> rule/advice" as I have not seen that, but rather that it should be a
>> reference to the versions/etc. and then we could/should have something like
>> Release-$SOver-$Maj.$Min.$Bug and have Release-$SOver point to the latest or
>> stablest/etc.
>
> I don't follow you. Where would that "pointer" exist? The latest we ship is
> always the latest for all platforms! ;-)
>
>> Ie. When we have feature changes, we need to find a way to indicate to the
>> application that makes use of the newer features, whether those features are
>> available or not...
>
> We do that by returning error in the functions that don't support the
> features you try to enable.
>
> We also provide the symbols-in-versions document to aid programmers to know
> at which point certain symbols appeared:
> http://github.com/bagder/curl/blob/master/docs/libcurl/symbols-in-versions
>
> I might also completely have misunderstood your points...
>
> --
>
>  / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette:  http://curl.haxx.se/mail/etiquette.html
>
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-09-23