From: Patrick McHardy <kaber@trash.net>
To: Eric Leblond <eric@inl.fr>
Cc: Robert Scott <rbscott@cadvium.net>,
netfilter-devel@lists.netfilter.org,
Pablo Neira Ayuso <pablo@netfilter.org>
Subject: Re: nfq_set_verdict_mark
Date: Fri, 13 Oct 2006 08:15:41 +0200 [thread overview]
Message-ID: <452F2F0D.1080502@trash.net> (raw)
In-Reply-To: <1160634939.24065.8.camel@localhost>
Eric Leblond wrote:
> Le mercredi 11 octobre 2006 à 23:47 +0200, Pablo Neira Ayuso a écrit :
>
>
>>We can warn about incompatibilities in the announce of new releases for
>>this kind of minor issues that we need to fix up and that result in
>>breakages, some kind of "heads up" section.
>
>
> Why not to add a API release number in the code.
>
> As developper of NuFW, I've got no problem to change my code but, I need
> a way to have my users not bored when they use my software. In fact I
> can not control which version of libnetfilter_queue.
>
> Something like "#define NFQUEUE_API_VERSION NNN" in libnetfilter_queue.h
> could really be used easily in application code to detect which flavour
> of the API they need to use.
That doesn't really solve the problem of incompatibilities. Any breakage
is really bad for a supposedly stable library. Pablo's suggestion about
adding new functions without breaking the old ones makes sense of
course, but there is no guarantee that we won't fuck up again. Which is
why I wanted to raise the question whether we want to continue this
way or go back to beta state until we're reasonable sure about the API.
Well, for now I guess the best way is to add the new functions and
go through a really long beta phase with the new API (after releasing
the current versions, which contain quite a few bugfixes since the
last release).
prev parent reply other threads:[~2006-10-13 6:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-01 20:09 nfq_set_verdict_mark Robert Scott
2006-10-02 14:55 ` nfq_set_verdict_mark Pablo Neira Ayuso
2006-10-10 5:20 ` nfq_set_verdict_mark Patrick McHardy
2006-10-10 23:59 ` nfq_set_verdict_mark Pablo Neira Ayuso
2006-10-11 9:02 ` nfq_set_verdict_mark Patrick McHardy
2006-10-11 21:47 ` nfq_set_verdict_mark Pablo Neira Ayuso
2006-10-12 6:35 ` nfq_set_verdict_mark Eric Leblond
2006-10-13 6:15 ` Patrick McHardy [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=452F2F0D.1080502@trash.net \
--to=kaber@trash.net \
--cc=eric@inl.fr \
--cc=netfilter-devel@lists.netfilter.org \
--cc=pablo@netfilter.org \
--cc=rbscott@cadvium.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.