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
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 you
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 exists.
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 is no
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), then we
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
On 04/30/06 04:46 Kevin P. Fleming said the following:
Sure, but since he said his changes were to astmanproxy, I doubt that is
the case.
yes, my changes here only referred to astmanproxy.
--
Regards, /\_/\ All dogs go to heaven.
[EMAIL PROTECTED]
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
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 attempt
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
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 it should
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
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
13 matches
Mail list logo
