Hi Jay, Jay Berkenbilt <[EMAIL PROTECTED]> writes:
> 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. Yes, I think experimental is a good place for this beta. > 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)? I think it would be a good idea to have both 2.8.0 and 3.0.0 since 3.0.0 is interface-incompatible with 2-series releases. Some applications may require a substantial effort to migrate from 2 to 3-series so I would expect some of them to stick with 2.8.0. We may also release 2.9.0 some time in the future if there is a demand from the community. > 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? It might make sense to be able to have both 3.0.0 and 3.1.0 installed at the same time. Generally, the Xerces-C++ release numbering policy is as follows: different major releases (e.g., 2.8.0 and 3.0.0) are interface-incompatible. Different minor releases (e.g., 3.0.0 and 3.1.0) are interface-compatible but binary-incompatible (that is, applications will need a recompile but no source code changes are necessary). Finally, different build releases (e.g., 3.0.0 and 3.0.1) are binary-compatible. Therefore, I think the current packaging schema is the most appropriate one. > 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. Hm, I agree there should be libxerces28 and libxerces30. However, I think there should only be one libxerces-dev since one cannot have both, say, 2.8.0 and 3.0.0 headers installed at the same time (they all end up in /usr/include/xercesc). In other words, a user can have several versions of libxerces-c.so installed but the development happens against only one version. Boris -- Boris Kolpackov, Code Synthesis Tools Open source XML data binding for C++: http://codesynthesis.com/products/xsd Mobile/embedded validating XML parsing: http://codesynthesis.com/products/xsde --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
