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
Attachment:
signature.asc
Description: Dette er en digitalt signert meldingsdel