Hi Juanjo! On Wed, 10 Sep 2008 00:10:10 +0200, Juan Jose Garcia-Ripoll wrote:
On Tue, Sep 9, 2008 at 11:15 PM, Luca Capello <luca@pca.it> wrote:
I'll play the Devil's advocate here, sorry: does this mean that 0.1.0 will be SONAME-compatible with 0.1.1?
The SONAME only uses the first two numbers. [...] Also, what is definitely true is that two libraries with different major (i.e. first) or minor (i.e. second) release numbers are not guaranteed to be binary compatible.
Noted, thanks.
Is a new release planned soon or should I package today's CVS snapshot to close this bug?
One or two weeks. Depends on another bug being closed and also how life develops.
OK, I'll ask the Debian Release Team about uploading a new upstream version at this time frame and then react accordingly.
CLISP provides a similar situation, but we (i.e. Debian) decided to ship only one version. What's your advice here?
I do not think it is politically correct to ask the maintainer of one implementation how the packaging of a different one should go, so please excuse if I do not answer that question.
I understand your point, but I think I wasn't enough clear: my question was/is not about how Debian should package CLISP, but what you prefer for ECL. Let's try again with different (and maybe clearer) words. I prefer to keep the ECL situation as it is now: Debian ships only one version, which is the latest release [1]. This means less work for the Debian maintainers (ATM mostly me) and also a more closer tracking of upstream development. The disadvantage is for anyone depending on ECL, who needs to "port" her/his applications to the new upstream release. Is it OK for you or have you other suggestions? I still think that splitting the main binary package into ecl and libecl can improve the situation WRT dependencies, but this is another matter. Thx, bye, Gismo / Luca Footnotes: [1] considering the Debian policies, i.e. if Debian's freezing for a new stable release, no new upstream versions are allowed in testing