[Evolution] Re: [Evolution-hackers] Request for adding version information to libcamel soname

[Øystein Gisnås]

Thanks for the quick, informative and constructive feedback. Although
this issue may have to be discussed more, I will go on as if there is a
consensus, just to keep the preparations for our release going.

ons, 26,.04.2006 kl. 12.50 +0530, skrev Parthasarathi Susarla:
> Camel, as such is more or less in a stable state has not changed much
> of-late. So the version name would be more or less the same across major
> releases, except when we break the API/ABI (which we intend to do for
> the 2.8 release). 

I'm not sure if I get this right. Do you intend to change interfaces so
that compatibility is broken, or are you saying compatibility is broken
by introducing versioning?

> > We highly value having the same names and versions in our releases as in
> > upstream. If you could give some indications on what changes will be
> > made upstream, and what names and versions will be used for this, we
> > could use that name/version scheme already and avoid future conflicts.
> Sure. we could start off with having the versioning done from the
> current stable release. But then again, we are already done with the
> major stable release (2.6) - and are in the minor release cycle, so
> there would be conflicts for users who would try to upgrade to these
> minor releases. 
> Am wondering if we should start off doing it on HEAD for now - so that
> we have this whole versioning system in place for the next stable
> release.
> 
> Any comments/suggestions?
> 
> -partha

I can understand that you don't want to introduce this for 2.6.x
releases. It would be great, however, if 2.8 could have the changes
implemented.

Debian will probably go with versioned libraries in all of 2.6 too,
which means breaking binary compatibility with other distributions
(including Ubutnu for now). Naturally getting in sync with upstream
versioning, however, is important for us, so that we don't have to
conflict with previous versions.

The most obvious scheme is that you use the versions already in
"configure.in", currently 8.0.1. If Camel keeps compatibility in the
next release, still use 8.0.1 (so that Debian don't have to bump
dependencies in this case), or bump versions from 8.0.1 if changes are
made. More simply put, we want assurance that the current version 8
won't be used if the API is changed.

Our second issue does not concern upstream in the same manner, but is
more of a question to the ones sitting on the knowledge. We currently
ship the libcamel providers (POP,IMAP++) in the same package as libcamel
and libcamel-provider. We want to move the providers to a different
package. The question is, what are the dependencies between e-d-s,
libcamel, libcamel-provider and the libcamel providers? What we've found
so far is that e-d-s needs libcamel, libcamel needs nothing,
libcamel-provider needs libcamel, and libcamel providers need all of
them. That would mean we could package (e-d-s, libcamel providers) which
would depend on (libcamel, libcamel-provider) so that for example
contact-lookup-applet can run without e-d-s (including libcamel
providers) installed, but only with libcamel (including
libcamel-provider). And what about versions and compatibility between
those libraries?

-Øystein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dette er en digitalt signert meldingsdel
Url : http://lists.alioth.debian.org/pipermail/pkg-evolution-maintainers/attachments/20060427/715ca6b4/attachment.pgp