Tzafrir Cohen wrote:
> For that reason I have asked you in this mailing list a while ago if the
> binary interface to modules is expected to remain stable along the 1.2
> series. You have answered that it is. Later on it was broken in 1.2.5
> (for a good cause, IIRC).
Yes, that was an exception
Anton wrote:
> Agree with difficulty of keeping so across major release
> versions.
And we don't make API changes inside major releases, only between them,
so the value of any such library would then be very little.
___
--Bandwidth and Colocation prov
On Mon, May 01, 2006 at 07:52:23AM -0500, Kevin P. Fleming wrote:
> Anton wrote:
>
> > There is a number of modules in fact, which are exist in the
> > binary form, and quite complicated to get them rebuilt or
> > updated to a new version, so if there is a way to keep
> > binary compatibility i
On 1 May 2006 17:52, Kevin P. Fleming wrote:
> I'm not aware of any other open source projects that
> attempt to preserve binary compatibility across major
> release versions. Certainly it is not the norm, and is an
> undue burden on the developers of the open source project
> to have to maintain c
Anton wrote:
> There is a number of modules in fact, which are exist in the
> binary form, and quite complicated to get them rebuilt or
> updated to a new version, so if there is a way to keep
> binary compatibility it should be kept.
I'm not aware of any other open source projects that attemp
>
> It need for linux distributions, for updating third part
> modules independent with asterisk.
There is a number of modules in fact, which are exist in the
binary form, and quite complicated to get them rebuilt or
updated to a new version, so if there is a way to keep
binary compatibility it
I need two things -- strict policy, and info about what patch would be
commited, if some issues would fixes, and what patch would not be
commited, and I doesn't need to spend my time for supporting this patches.
There is no answer to that question before the patch exists. We can
certainly tell
On Mon, May 01, 2006 at 06:48:11AM -0500, Kevin P. Fleming wrote:
>> This moving helps to minimize duplicate code and improve API stability
>> without affecting development speed.
KPF> This is incorrect. As soon as 'struct ast_channel' is part of the
KPF> library's API (as it would have to be), th
On Mon, May 01, 2006 at 07:11:47AM -0500, Kevin P. Fleming wrote:
>> I need two things -- strict policy, and info about what patch would be
>> commited, if some issues would fixes, and what patch would not be
>> commited, and I doesn't need to spend my time for supporting this patches.
KPF> There
Denis Smirnov wrote:
> I need two things -- strict policy, and info about what patch would be
> commited, if some issues would fixes, and what patch would not be
> commited, and I doesn't need to spend my time for supporting this patches.
There is no answer to that question before the patch exist
On Sun, Apr 30, 2006 at 04:28:41PM -0500, Tilghman Lesher wrote:
TL> In the future, to avoid these types of problems, I recommend that if
TL> one of your bugs is closed, that you seek out either the person who
TL> closed them or another bug marshal, either via email or via IRC, to
TL> discuss why
Denis Smirnov wrote:
> This moving helps to minimize duplicate code and improve API stability
> without affecting development speed.
This is incorrect. As soon as 'struct ast_channel' is part of the
library's API (as it would have to be), then we cannot make changes to
the channel structure witho
12 matches
Mail list logo
