Boris Kolpackov <[EMAIL PROTECTED]> wrote: > Hi, > > The first beta for the upcoming Xerces-C++ 3.0.0 release is > available for download: > > http://people.apache.org/builds/xerces/c/ > > The purpose of this beta is to allow all interested parties to > test the new autotools-based build system on various platforms > as well as to make sure that no regressions have been introduced > compared to 2.8.0. > . . .
I'm the debian maintainer for the xerces-c packages. Would it be appropriate to upload this beta to debian's experimental distribution (not used by end users) so that people who use packages that depend on xerces 2.7.0 or 2.8.0 can try their stuff with 3.0.0? I would not upload this into the main distribution until the final 3.0.0 is out. Since there have sometimes been incompatibilities between the various versions, there have historically been multiple xerces versions in debian at the same time. To be clear, I'm not saying that there are lots of incompatibilities, but there are a few packages, such as xalan, shibboleth, and perhaps a few others I'm forgetting, that have required a little extra effort to migrate from one version to the next. In order to keep the xerces transitions from being very long, we've just allowed multiple versions of xerces to coexist in spite of the fact that there is a general preference not to do this. Do you think it would be important to have both 2.8.0 and 3.0.0 in debian at the same time, or would it be better to try to get just one version (3.0.0)? If you could pretty much say that every application that works with 2.7.0 or 2.8.0 could be made to work with 3.0.0 with little or no source code change, then I would lean in favor of having just one version of the package. Going forward, do you think it would be prudent to continue packaging xerces so that 3.0.0 and, say, 3.1.0 could coexist, or do you expect future migrations from one version to the next to be a little easier than with the 2.x packages? The real question has to do with source compatibility. Binary compatibility is not an issue -- there are mechanisms for handling that. But if there is an expectation of source compatibility being the norm from one release to the next, then I will take advantage of this opportunity to redo the xerces packages with the assumption that there will be only one version of xerces-c at a time. For those of you who are debian users, but what I'm really getting at is whether the source package should just be xerces-c or whether it should be xerces30 or something like that (analogous to the current xerces27 and xerces28 packages). Likewise, the development packages could be libxerces-c-dev instead of libxerces27-dev, libxerces28-dev, etc. As long as there is usually going to be source compatibility, this change would make it easier for debian to take new xerces versions. The one thing I think would probably be a casualty would be xerces-p (XML::Xerces perl), but I don't think very many people are using that, and it doesn't seem to be actively maintained. (Correct me if I'm wrong.) --Jay -- Jay Berkenbilt <[EMAIL PROTECTED]> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
