Ivan Čukić wrote:
> I do agree that is would be a proper way to handle it. The only
> problem I see with it is that the point is actually not to provide
> binary compatibility, nor proper handling of BIC.
>
> At least in the case I have. Namely, the point is for the library to
> be used *only* for
Hi Kevin,
I do agree that is would be a proper way to handle it. The only
problem I see with it is that the point is actually not to provide
binary compatibility, nor proper handling of BIC.
At least in the case I have. Namely, the point is for the library to
be used *only* for things that are in
Ivan Čukić wrote:
> - 0 soversion to show that the library has no stable ABI.
I'd actually set both the soname and the fully-versioned name to
libfoo.so.0.1, then if you change something binary-incompatibly,
libfoo.so.0.2, etc. (or use libfoo.so.0.1 etc. as the soname and something
like libfoo.
> The C++ committee uses (for example)
> std::experimental::something
I was thinking about something along these lines as well.
> say it's a "technology preview"
Both would be ok I guess, the only problem I see with TP is that is
one does not read the README, it might be missed.
I'd propose to
On Fri, Jan 9, 2015 at 5:34 PM, Ivan Čukić wrote:
> Hi,
>
> Because of the short release cycle for the frameworks, it is hard to
> have bigger new features included into one of them. Slowly evolving
> APIs while developing stuff leaves a lot of crud and deprecated
> methods later.
>
> What is our
Hi,
Because of the short release cycle for the frameworks, it is hard to
have bigger new features included into one of them. Slowly evolving
APIs while developing stuff leaves a lot of crud and deprecated
methods later.
What is our policy about having experimental (unstable API/ABI) parts
in a fr
