xerces-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Boris Kolpackov <bo...@codesynthesis.com>
Subject Re: Xerces-C++ 3.0.0 beta 1 released
Date Sat, 15 Mar 2008 19:36:58 GMT
Hi Jay,

Jay Berkenbilt <ejb@ql.org> 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: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org


Mime
View raw message