You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by Boris Kolpackov <bo...@codesynthesis.com> on 2008/03/13 15:14:38 UTC
Xerces-C++ 3.0.0 beta 1 released
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.
Below is the list of new features and improvements in 3.0.0 that
could serve as good reasons to upgrade from 2.8.0 and thus help
us test this beta:
- Better build system (autotools) for UNIX/Linux platforms
- Project files for VC 9
- Support for the ICU transcoder in VC 7.1, 8, and 9 project files
- libcurl-based net accessor
- Support for XInclude
- Support for a subset of XPath
- Conformance to the final DOM Level 3 interface specification
- Ability to provide custom DOM memory manager
- Better 64-bit support
- Cleaned up error messages
- Better tested, including against W3C XML Schema test suite
- Removal of the deprecated code
Some UNIX platforms (e.g., AIX, Solaris, etc.) may require extra
configure and/or make options which are listed on the following
page (these will be incorporated into the build instructions
before the final release):
http://wiki.apache.org/xerces/XercescBuildStatus
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
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Jay,
Jay Berkenbilt <ej...@ql.org> writes:
> Oh, I didn't realize it was bundled with xerces-c now, or has it been?
> In that case, there should be no problem.
>
> (looking at the distribution)
>
> Hmm. I don't see it. Am I missing something? Where can I get a
> xerces-p that will work with 3.0.0?
Xerces-P hasn't been packaged with this beta since it is not ready
yet. Also it is not yet clear whether it will be in the final release
since nobody has stepped up to maintain it in the long term. See the
following discussion for more information:
http://marc.info/?t=120488420100001&r=1&w=2
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
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Jason Stewart <ja...@gmail.com>.
Hey Boris,
On 22/03/2008, Boris Kolpackov <bo...@codesynthesis.com> wrote:
> Hi Alberto,
>
> My original point still holds: it may look simple but it probably
> won't support all the platforms that Xerces-C++ supports. Plus,
> after some clarification from Jason, it does not seem right to
> build swig/util with Perl since, if I understood this correctly,
> it will be used with other scripting languages. In other words,
> swig/util might need to be build on a box without Perl.
>
This is correct. I would like swig/util built out of the box without
support for any language in particular - it exists to help the
scripting languages interface to specific Xerces features.
Cheers, jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Jason Stewart <ja...@gmail.com>.
Hey Alberto,
On 22/03/2008, Alberto Massari <am...@datadirect.com> wrote:
> If we can remove this dependency on configure and autoconf, it would be
> possible for Xerces to work regardless of the presence of the swig
> subdir.
Ah... Now I see the issue... if we remove the swig directory from the
distribution, then autoconf will fail? I didn't realize that.
Is there a way to make the Makefiles in the swig dir optional?
Otherwise I think it is best to remove all knowledge of the swig dir
from the top-level files.
> The perl binding would then be built either manually (cd swig;
> perl Makefile.PL; make -C perl test) or from the Xerces directory (make
> test-suite).
The code in swig/util/ is a library that depends on libxerces and the
header files, that's all. We just need a simple Makefile to compile it
- I added it into the autoconf files because they existed and it took
advantage of all the work already done by Xerces.
Maybe if we have a seperate distribution for Xerces-P, it can include
different top-level configure.ac and Makefile.am that includes the
swig/ dir?
Cheers, jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Message regenaration for XERCESC-1790 fix
Posted by Alberto Massari <am...@datadirect.com>.
Done.
Alberto
Boris Kolpackov wrote:
> Hi Alberto,
>
> I've committed a fix for XERCESC-1790[1] but didn't regenerate all
> the various message files. Could you please do it when you have a
> chance?
>
> [1] https://issues.apache.org/jira/browse/XERCESC-1790
>
> Thanks,
> Boris
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: c-dev-help@xerces.apache.org
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Message regenaration for XERCESC-1790 fix
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Alberto,
I've committed a fix for XERCESC-1790[1] but didn't regenerate all
the various message files. Could you please do it when you have a
chance?
[1] https://issues.apache.org/jira/browse/XERCESC-1790
Thanks,
Boris
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Alberto,
Alberto Massari <am...@datadirect.com> writes:
> while the one in perl\Handler is even simpler:
>
> WriteMakefile(
> LINKTYPE => 'static',
> 'NAME' => 'Handler',
> 'INC' => $INCLUDES,
> 'OBJECT' => '$(O_FILES)',
> 'LIBS' => [$LIBS],
> 'CCFLAGS' => $CFLAGS,
> 'CC' => $CXX,
> 'SKIP' => [qw( dynamic test makeaperl xs_o)],
> @OPTIMIZE,
> @LDFLAGS,
> );
My original point still holds: it may look simple but it probably
won't support all the platforms that Xerces-C++ supports. Plus,
after some clarification from Jason, it does not seem right to
build swig/util with Perl since, if I understood this correctly,
it will be used with other scripting languages. In other words,
swig/util might need to be build on a box without Perl.
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
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Gareth Reakes <ga...@we7.com>.
>
> In the meanwhile, it would be helpful if a user could decide to
> download just Xerces-C or the combination Xerces-C+Xerces-P, so that
> we can get some metrics on the interests of the silent developers.
> This implies that "configure" should not process makefiles in the
> swig directory, so it can live without that folder in the
> distribution (and swig/Makefile can avoid implementing special
> targets required by autoconf).
>
Whichever method we go for in the distribution I think some
measurement would be useful. I will set p a google analytics account
so we can see downloads.
Gareth
--
Gareth Reakes, CTO WE7
+44-20-7117-0809 http://www.we7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Alberto Massari <am...@datadirect.com>.
Disclaimer: I don't know how perl extension are built, and how swig
works....
I'm basing my idea on the fact that the swig\perl\Transcoder has a
Makefile.PL with this content:
WriteMakefile(
LINKTYPE => 'static',
'NAME' => 'Transcoder',
'INC' => $INCLUDES,
'OBJECT' => '$(O_FILES)',
'CCFLAGS' => $CFLAGS,
'LIBS' => [$LIBS],
'CC' => $CXX,
'SKIP' => [qw( dynamic test makeaperl xs_o)],
@OPTIMIZE,
@LDFLAGS,
);
__END__
sub MY::static
{
'
static :: libtranscode$(LIB_EXT)
dynamic :: static
libtranscode$(LIB_EXT): $(O_FILES) $(MYEXTLIB)
$(AR) cru libtranscode$(LIB_EXT) $(O_FILES)
$(RANLIB) libtranscode$(LIB_EXT)
libtranscode.$(DLEXT): $(LDFROM) $(MYEXTLIB)
$(LD) -o libtranscode.$(DLEXT) $(LDDLFLAGS) --whole-archive
$(LDFROM) $(OTHERLDFLAGS) $(MYEXTLIB) $(PERL_ARCHIVE) $(LDLOADLIBS)
$(EXPORT_LIST)
$(CHMOD) 755 libtranscode.$(DLEXT)
';
}
while the one in perl\Handler is even simpler:
WriteMakefile(
LINKTYPE => 'static',
'NAME' => 'Handler',
'INC' => $INCLUDES,
'OBJECT' => '$(O_FILES)',
'LIBS' => [$LIBS],
'CCFLAGS' => $CFLAGS,
'CC' => $CXX,
'SKIP' => [qw( dynamic test makeaperl xs_o)],
@OPTIMIZE,
@LDFLAGS,
);
Both projects are listed in the perl\Makefile.PL in the same way the
util\Makefile is referenced, i.e.
$HANDLER_LIB:
\$(MAKE) -C Handler static
$TRANSCODER_LIB:
\$(MAKE) -C Transcoder static
$UTIL_LIB:
\$(MAKE) -C $SWIG_DIR
So, given that the XMLExceptionHandler.cpp is compiled into a static
library just like the other two, wouldn't it be simpler to convert it to
use the same makefile of the Handler subdirectory?
If we can remove this dependency on configure and autoconf, it would be
possible for Xerces to work regardless of the presence of the swig
subdir. The perl binding would then be built either manually (cd swig;
perl Makefile.PL; make -C perl test) or from the Xerces directory (make
test-suite).
Alberto
Boris Kolpackov wrote:
> Hi Alberto,
>
> Alberto Massari <am...@datadirect.com> writes:
>
>
>> Jason, would it be possible to implement the libutil.a helper library
>> like you do with the libTranscoder.a, i.e. using Makefile.PL instead of
>> Makefile.am?
>>
>
> I don't think it is such a good idea. I doubt the Makefile.PL build
> system has the same cross-platform support for C++ as automake. Using
> Makefile.PL to build C++ libraries is just asking for trouble.
>
> If we want to split swig and Xerces-C++ then the proper way to do it
> would be for the swig directory to have its own configure script. Then
> we can package swig as an "add-on" to the Xerces-C++ distribution in
> the same way as we have done for the tools directory.
>
> Boris
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Alberto,
Alberto Massari <am...@datadirect.com> writes:
> Jason, would it be possible to implement the libutil.a helper library
> like you do with the libTranscoder.a, i.e. using Makefile.PL instead of
> Makefile.am?
I don't think it is such a good idea. I doubt the Makefile.PL build
system has the same cross-platform support for C++ as automake. Using
Makefile.PL to build C++ libraries is just asking for trouble.
If we want to split swig and Xerces-C++ then the proper way to do it
would be for the swig directory to have its own configure script. Then
we can package swig as an "add-on" to the Xerces-C++ distribution in
the same way as we have done for the tools directory.
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
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Alberto Massari <am...@datadirect.com>.
Boris, Gareth,
I agree that the committers cannot check that the build is sane in every
component/platform; that's why we have the wiki page where we annotate
what works and what doesn't work in a bunch of platforms that we try to
test regularly. Xerces-P is currently at the same level of Win32+Borland
(someone can test it twice a year), but better than AS/400 (nobody has
an idea of where to get a machine, and how to compile on it).
Before we release a version, we try to test (and fix) as many platforms
we can, and if one of them doesn't build, it's out of the list of
supported platforms. For 3.0, Xerces-P would be in the distribution, as
Jason found the time to fix it; for 3.1, if Jason cannot do it and
nobody else stepped in to do it, it will be out of the distribution.
In the meanwhile, it would be helpful if a user could decide to download
just Xerces-C or the combination Xerces-C+Xerces-P, so that we can get
some metrics on the interests of the silent developers. This implies
that "configure" should not process makefiles in the swig directory, so
it can live without that folder in the distribution (and swig/Makefile
can avoid implementing special targets required by autoconf).
Jason, would it be possible to implement the libutil.a helper library
like you do with the libTranscoder.a, i.e. using Makefile.PL instead of
Makefile.am?
Alberto
Boris Kolpackov wrote:
> Hi Gareth,
>
> Gareth Reakes <ga...@we7.com> writes:
>
>
>> 1 - is anyone downloading / using P
>>
>
> That's not going to be easy since Xerces-P will now be part of
> the Xerces-C++ distribution.
>
>
>
>> 2 - is it painful for the contributors to check they have not broken
>> the bindings
>> 3 - whether Jason or someone can help when there are problems
>>
>
> My position is the same: I don't mind having Xerces-P be part of
> the distribution if we have someone to maintain it. I, however,
> do not want to be forced to run extra tests every time I change
> something plus learn another programming language (Perl) and
> technology (swig) to fix stuff that I am not even interested in.
> As I side note, I wonder how contributors who use Windows/VC++
> as their development platform are going to run swig tests since,
> AFAICT, swig can only be built with make.
>
> (BTW, I don't think the argument that we already have to make sure
> our changes don't break other parts of Xerces-C++ applies here. In
> this case we have a whole new programming language and technology
> involved).
>
> I would therefore prefer an alternative approach:
>
> 1. The contributors don't have to make sure their changes are not
> breaking swig.
>
> 2. Before the release, if something is not working in swig, we
> ask all interested parties on the mailing list to fix it. If
> this does not happen we move swig to the attic and release
> this version without swig.
>
> 3. If at some point we get someone interested in getting swig
> back into shape, we move it back from attic to trunk.
>
> To make it clear, I don't have anything against Xerces-P or swig.
> I don't particularly like how from a project that depends on
> Xerces-C++ it transitioned into a project that is part of Xerces-C++
> and now tries to force me to maintain it. But this decision was made
> before I got involved with the project.
>
>
> 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
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
RE: Xerces-C++ 3.0.0 beta 1 released
Posted by Scott Cantor <ca...@osu.edu>.
> My position is the same: I don't mind having Xerces-P be part of
> the distribution if we have someone to maintain it. I, however,
> do not want to be forced to run extra tests every time I change
> something
Seems like that's what having a maintainer implies, somebody to do that
periodically.
> 2. Before the release, if something is not working in swig, we
> ask all interested parties on the mailing list to fix it. If
> this does not happen we move swig to the attic and release
> this version without swig.
>
> 3. If at some point we get someone interested in getting swig
> back into shape, we move it back from attic to trunk.
The problem with this is that people can't depend on having it maintained,
so it won't be used. It becomes a self-fulfilling situation.
> To make it clear, I don't have anything against Xerces-P or swig.
I didn't have anything against all the various options and platforms either,
but when I noted that it seemed like the project either had to have
maintainers step up or drop them to get 3.0 done I was accused of heresy.
Still seems like common sense to me.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Gareth,
Gareth Reakes <ga...@we7.com> writes:
> 1 - is anyone downloading / using P
That's not going to be easy since Xerces-P will now be part of
the Xerces-C++ distribution.
> 2 - is it painful for the contributors to check they have not broken
> the bindings
> 3 - whether Jason or someone can help when there are problems
My position is the same: I don't mind having Xerces-P be part of
the distribution if we have someone to maintain it. I, however,
do not want to be forced to run extra tests every time I change
something plus learn another programming language (Perl) and
technology (swig) to fix stuff that I am not even interested in.
As I side note, I wonder how contributors who use Windows/VC++
as their development platform are going to run swig tests since,
AFAICT, swig can only be built with make.
(BTW, I don't think the argument that we already have to make sure
our changes don't break other parts of Xerces-C++ applies here. In
this case we have a whole new programming language and technology
involved).
I would therefore prefer an alternative approach:
1. The contributors don't have to make sure their changes are not
breaking swig.
2. Before the release, if something is not working in swig, we
ask all interested parties on the mailing list to fix it. If
this does not happen we move swig to the attic and release
this version without swig.
3. If at some point we get someone interested in getting swig
back into shape, we move it back from attic to trunk.
To make it clear, I don't have anything against Xerces-P or swig.
I don't particularly like how from a project that depends on
Xerces-C++ it transitioned into a project that is part of Xerces-C++
and now tries to force me to maintain it. But this decision was made
before I got involved with the project.
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
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Gareth Reakes <ga...@we7.com>.
Hey Jason,
Boris and others, what about this as a suggestion. Jason seems happy
to get it out the door for this release. I suggest we do and and then
monitor 3 things before deciding whether to continue for following
releases:
1 - is anyone downloading / using P
2 - is it painful for the contributors to check they have not broken
the bindings
3 - whether Jason or someone can help when there are problems
If we have problems then we can dump it at 3.1. What do you think?
Gareth
On 20 Mar 2008, at 05:01, Jason Stewart wrote:
> Hey Gareth and Boris,
>
> I'm pretty calm about the whole thing. It's been really super being
> part of the Xerces team for seven years - even if my total
> contribution hasn't been all that much. I do not have any ego at stake
> as to whether Xerces-P survives the chopping block.
>
> If people want it around, then I think they should speak up.
>
> And it would be a big help to me if others would help maintain the
> bindings. But the swig bindings are beyond most Perl users (or Python
> or Ruby users too). They are all C++ - and pretty involved C++.
>
> To see if something breaks - it is now as simple as doing a make
> test-suite, and we should see all tests pass. If individual tests
> fail, they can be run manually to generate more output to indicate why
> they failed.
>
> Usually the problem is that some class header file changes, and some
> method has a new type signature and the library won't link. When that
> happens, the SWIG-generated C++ files need to be regenerated by
> running swig. So usually, it is pretty simple. What has created
> trouble for me in the past is upgrading to more recent versions of
> SWIG to gain new features... This has caused me to rewrite the
> interface definition files, and that often takes debugging time. But
> if we stick with a given SWIG version, creating a new release of
> xerces-p is as simple as rerunning swig and recompiling.
>
> As I mentioned last year, I would love to see the test-suite grow to
> include all the classes of the public Xerces API and all the methods.
> Right now, I'm guessing the coverage is less than 50%. This may be
> seen as a reason for keeping the SWIG bindings around. The Perl test
> harness is VERY helpful for unit testing - but of course I'm a Perl
> programmer...
>
> Again, I'm open to suggestions.
>
> Cheers, jas.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
> For additional commands, e-mail: c-dev-help@xerces.apache.org
>
>
--
Gareth Reakes, CTO WE7
+44-20-7117-0809 http://www.we7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Jason Stewart <ja...@gmail.com>.
Hey Gareth and Boris,
I'm pretty calm about the whole thing. It's been really super being
part of the Xerces team for seven years - even if my total
contribution hasn't been all that much. I do not have any ego at stake
as to whether Xerces-P survives the chopping block.
If people want it around, then I think they should speak up.
And it would be a big help to me if others would help maintain the
bindings. But the swig bindings are beyond most Perl users (or Python
or Ruby users too). They are all C++ - and pretty involved C++.
To see if something breaks - it is now as simple as doing a make
test-suite, and we should see all tests pass. If individual tests
fail, they can be run manually to generate more output to indicate why
they failed.
Usually the problem is that some class header file changes, and some
method has a new type signature and the library won't link. When that
happens, the SWIG-generated C++ files need to be regenerated by
running swig. So usually, it is pretty simple. What has created
trouble for me in the past is upgrading to more recent versions of
SWIG to gain new features... This has caused me to rewrite the
interface definition files, and that often takes debugging time. But
if we stick with a given SWIG version, creating a new release of
xerces-p is as simple as rerunning swig and recompiling.
As I mentioned last year, I would love to see the test-suite grow to
include all the classes of the public Xerces API and all the methods.
Right now, I'm guessing the coverage is less than 50%. This may be
seen as a reason for keeping the SWIG bindings around. The Perl test
harness is VERY helpful for unit testing - but of course I'm a Perl
programmer...
Again, I'm open to suggestions.
Cheers, jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Gareth Reakes <ga...@we7.com>.
On 18 Mar 2008, at 07:37, Boris Kolpackov wrote:
> Hi Gareth,
>
> Gareth Reakes <ga...@we7.com> writes:
>
>> I think it will be much easier to maintain now it is part of xerces.
>> Its not actually hard to change the SWIG files if you know you have
>> broken them.
>
> Well, I don't know anything about swig so I wouldn't know when I broke
> it and how to fix it. I also don't see a reason why Xerces-C++
> maintainers who are otherwise not interested in perl binding and/or
> swig have to learn about this stuff. To me this idea sounds like
> another hurdle one has to overcome when developing and maintaining
> the project. It makes even less sense when we consider that nobody
> seems to be interested in this feature (see Jason's earlier email
> as well as the Debian popularity contest results).
Well, there are many parts of Xerces that I may not be interested in
and yet I still fix the build if I break them. The question for me is
are users interested. If they are not then there is not even any need
to worry about whether we have a maintainer.
Gareth
--
Gareth Reakes, CTO WE7
+44-20-7117-0809 http://www.we7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Gareth,
Gareth Reakes <ga...@we7.com> writes:
> I think it will be much easier to maintain now it is part of xerces.
> Its not actually hard to change the SWIG files if you know you have
> broken them.
Well, I don't know anything about swig so I wouldn't know when I broke
it and how to fix it. I also don't see a reason why Xerces-C++
maintainers who are otherwise not interested in perl binding and/or
swig have to learn about this stuff. To me this idea sounds like
another hurdle one has to overcome when developing and maintaining
the project. It makes even less sense when we consider that nobody
seems to be interested in this feature (see Jason's earlier email
as well as the Debian popularity contest results).
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
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Gareth Reakes <ga...@we7.com>.
On 18 Mar 2008, at 00:15, Boris Kolpackov wrote:
> As Jason mentioned in one of his emails, he asked a number of
> scripting
> language communities whether they would be interested in Xerces-C++
> binding. Apparently nobody was interested.
>
> My position boils down to the following: if we cannot find a permanent
> maintainer for swig then we should move it to attic (new SVN module
> for unused code). Releasing 3.0.0 with swig but without permanent
> maintainer would give a false impression to the users that this
> functionality will be maintained and supported in the future. If,
> at some point, we find someone interested in maintaining swig we
> can always move it back to the trunk.
I think it will be much easier to maintain now it is part of xerces.
Its not actually hard to change the SWIG files if you know you have
broken them.
Gareth
--
Gareth Reakes, CTO WE7
+44-20-7117-0809 http://www.we7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Gareth,
Gareth Reakes <ga...@we7.com> writes:
> >If the Xerces-C team thinks it's valuable to include Xerces-P, then it
> >will make it into the release.
>
> I think it is valuable.
It is not really a question of whether it is valuable or not but rather
of whether there is someone to develop and maintain it in the long term.
So far Jason stepped up to get it into the compilable state but nobody
committed to maintaining it in the long run. And my understanding is
that swig is not something that can just sit there without requiring
much attention since it needs updating every time the interface
changes.
> I think there is a good chance to get further bindings now the
> process is easier.
As Jason mentioned in one of his emails, he asked a number of scripting
language communities whether they would be interested in Xerces-C++
binding. Apparently nobody was interested.
My position boils down to the following: if we cannot find a permanent
maintainer for swig then we should move it to attic (new SVN module
for unused code). Releasing 3.0.0 with swig but without permanent
maintainer would give a false impression to the users that this
functionality will be maintained and supported in the future. If,
at some point, we find someone interested in maintaining swig we
can always move it back to the trunk.
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
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Gareth Reakes <ga...@we7.com>.
> If the Xerces-C team thinks it's valuable to include Xerces-P, then it
> will make it into the release.
I think it is valuable. I think there is a good chance to get further
bindings now the process is easier.
Gareth
--
Gareth Reakes, CTO WE7
+44-20-7117-0809 http://www.we7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Jason Stewart <ja...@gmail.com>.
Hi Jay,
On 18/03/2008, Jay Berkenbilt <ej...@ql.org> wrote:
> I'd like to keep the libxml-xerces-perl package in debian. If you'd
> be willing to help out in the event of trouble, then I will try to
> keep it in.
Sure, just let me know. I do all my development on Ubuntu.
> Hopefully the issues that are causing trouble can worked out before
> 3.0.0, but if not and you can provide something after the release, I
> can still package it.
Happy to help. jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Jay Berkenbilt <ej...@ql.org>.
"Jason Stewart" <ja...@gmail.com> wrote:
> Xerces-p is built by running swig on the latest version of Xerces-C
> and then compiling the swig-generated .cpp files against the xerces-c
> library.
>
> In my experience as maintainer from the Xerces-C 1.x until now - there
> have been changes in the header files that make it impossible to
> compile swig-generated source files from a previous release against
> the library from the latest release. Therefore I added the simple
> check against the version number - if it fails to find the version it
> expects it issues a warning. We used to get a lot of complaints on the
> list with people trying to build old xerces-p releases against newer
> xerces-c libraries.
>
> Cheers, jas.
I'd like to keep the libxml-xerces-perl package in debian. If you'd
be willing to help out in the event of trouble, then I will try to
keep it in.
Hopefully the issues that are causing trouble can worked out before
3.0.0, but if not and you can provide something after the release, I
can still package it.
--Jay
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Jason Stewart <ja...@gmail.com>.
Hey Jay,
On 15/03/2008, Jay Berkenbilt <ej...@ql.org> wrote:
> "Jason Stewart" <ja...@gmail.com> wrote:
>
> > I was curious why xerces-p would be a casualty? The primary struggle
> > I've had as xerces-p maintainer was xerces-c's alternate build system.
> > Now that it fully supports the GNU toolchain, xerces-p is bundled with
> > xerces-c as a subproject. Shouldn't that make it easier for debian?
>
>
> Oh, I didn't realize it was bundled with xerces-c now, or has it been?
> In that case, there should be no problem.
>
> (looking at the distribution)
>
> Hmm. I don't see it. Am I missing something? Where can I get a
> xerces-p that will work with 3.0.0?
>
It was not included with the beta, it is in subversion under the
swig/perl/ directory. There is one bug that is currently keeping it
from compiling due to my ignorance of autoconf/automake.
If the Xerces-C team thinks it's valuable to include Xerces-P, then it
will make it into the release.
> > I don't think there are many active users of xerces-p, so if it was
> > dropped out of debian, those that wanted it could get it from CPAN.
>
>
> True enough. Anyway, I'll keep it in if I can. I just didn't realize
> there was a version that worked with > 2.7.0. My source of
> information is the Xerces P link on xerces.apache.org. I also see
> that 2.7.0 is the latest version on CPAN.
>
> For what it's worth, I made a quick attempt to package XML::Xerces
> 2.7.0 with 2.8.0, and the configuration complained that the versions
> didn't match. I didn't make any attempts to override it.
>
Xerces-p is built by running swig on the latest version of Xerces-C
and then compiling the swig-generated .cpp files against the xerces-c
library.
In my experience as maintainer from the Xerces-C 1.x until now - there
have been changes in the header files that make it impossible to
compile swig-generated source files from a previous release against
the library from the latest release. Therefore I added the simple
check against the version number - if it fails to find the version it
expects it issues a warning. We used to get a lot of complaints on the
list with people trying to build old xerces-p releases against newer
xerces-c libraries.
Cheers, jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Jay Berkenbilt <ej...@ql.org>.
"Jason Stewart" <ja...@gmail.com> wrote:
> I was curious why xerces-p would be a casualty? The primary struggle
> I've had as xerces-p maintainer was xerces-c's alternate build system.
> Now that it fully supports the GNU toolchain, xerces-p is bundled with
> xerces-c as a subproject. Shouldn't that make it easier for debian?
Oh, I didn't realize it was bundled with xerces-c now, or has it been?
In that case, there should be no problem.
(looking at the distribution)
Hmm. I don't see it. Am I missing something? Where can I get a
xerces-p that will work with 3.0.0?
> I don't think there are many active users of xerces-p, so if it was
> dropped out of debian, those that wanted it could get it from CPAN.
True enough. Anyway, I'll keep it in if I can. I just didn't realize
there was a version that worked with > 2.7.0. My source of
information is the Xerces P link on xerces.apache.org. I also see
that 2.7.0 is the latest version on CPAN.
For what it's worth, I made a quick attempt to package XML::Xerces
2.7.0 with 2.8.0, and the configuration complained that the versions
didn't match. I didn't make any attempts to override it.
--Jay
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Jason Stewart <ja...@gmail.com>.
Hey Jay
On 15/03/2008, Jay Berkenbilt <ej...@ql.org> wrote:
> 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.)
>
I was curious why xerces-p would be a casualty? The primary struggle
I've had as xerces-p maintainer was xerces-c's alternate build system.
Now that it fully supports the GNU toolchain, xerces-p is bundled with
xerces-c as a subproject. Shouldn't that make it easier for debian?
I don't think there are many active users of xerces-p, so if it was
dropped out of debian, those that wanted it could get it from CPAN.
Cheers, jas.
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Jay Berkenbilt <ej...@ql.org>.
Boris Kolpackov <bo...@codesynthesis.com> wrote:
>> There has to be a separate -dev package for each source package,
>> though it's okay if libxerces-c-dev belongs to the most recent one and
>> older ones, if any, have a numbered libxerces-cnn-dev package. This
>> is how the Berkeley DB packages are managed.
>
> Hm, I guess it can be done either way. For example, there are libicu34,
> libicu36, and libicu38, however, only one libicu-dev. You schema has
> an advantage of allowing both, say, libxerces-2-dev and libxerces-3-dev
> to be in the repository with the user being able to select which to
> install. I would, however, suggest that we use the major release number
> in both -dev packages so that they correspond to libxerces-c packages
> (that is libxerces-2 and libxerces-2-dev, libxerces-3 and libxerces-3-dev).
I'm planning on having libxerces-c-dev "provide" libcxerces-c3-dev.
That means people can select libxerces-c3-dev explicitly if they
choose, but the name "libxerces-c-dev" will always belong to the
latest version. This is the same scheme used by Berkeley DB, and I
think it works nicely because it means you have to take specific
action to not depend on the latest version.
ICU is another good example. Actually, I'm also the debian maintainer
for ICU (not coincidentally -- it's because it's a dependency of
xerces that I took over the package when its previous maintainer
retired). The libicu34, libicu36, and libicu38 packages all came from
different versions of the icu source package. There's no way in lenny
(or sid/unstable) to install libicu34 or libicu36 anymore since the
icu source package no longer supplies them. By having the -dev
package be libicu-dev instead of libicu38-dev, the next
source-compatible ICU release can be a binary only transition.
Otherwise, people have to change their source packages to change the
build dependencies from libicu34-dev to libicu36-dev to libicu38-dev.
In fact, I used to have the soname version in the -dev package, but
over time, I realized that doing so makes library transitions harder.
For people who need to specify an exact version, they can use
versioned dependencies.
--Jay
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Jay,
Jay Berkenbilt <ej...@ql.org> writes:
> Many thanks for your quick response and to all your good work on
> getting these releases out. When I saw your message about preparing
> 3.0.0, I knew it would actually happen. :-)
Don't jinx it! ;-) Xercec-C++ 3.0.0 was "almost there" for many years
now.
> The release numbering scheme you've described sounds quite sensible
> and standard. However, based on your answer, my inclination would be
> to change the debian packaging scheme to support only one version of
> xerces 3.x in the archive at a time.
Ok, after reading your explanation it makes sense.
> The only reason I bring up the question at all is that, in the past,
> it has not always been the case that subsequent minor releases are
> source compatible. At least, this is the case with XML::Xerces (a.k.a.
> xerces-p, or debian package libxml-xerces-perl) which depends on a
> specific minor version of xerces-c.
I wouldn't worry about it since this is actually a problem in Xerces-P
not Xerces-C++. If someone is interested in pre-3.0.0 Xerces-P then
they will have to fix this.
> There has to be a separate -dev package for each source package,
> though it's okay if libxerces-c-dev belongs to the most recent one and
> older ones, if any, have a numbered libxerces-cnn-dev package. This
> is how the Berkeley DB packages are managed.
Hm, I guess it can be done either way. For example, there are libicu34,
libicu36, and libicu38, however, only one libicu-dev. You schema has
an advantage of allowing both, say, libxerces-2-dev and libxerces-3-dev
to be in the repository with the user being able to select which to
install. I would, however, suggest that we use the major release number
in both -dev packages so that they correspond to libxerces-c packages
(that is libxerces-2 and libxerces-2-dev, libxerces-3 and libxerces-3-dev).
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
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Jay Berkenbilt <ej...@ql.org>.
Many thanks for your quick response and to all your good work on
getting these releases out. When I saw your message about preparing
3.0.0, I knew it would actually happen. :-)
Boris Kolpackov <bo...@codesynthesis.com> wrote:
>> 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.
The release numbering scheme you've described sounds quite sensible
and standard. However, based on your answer, my inclination would be
to change the debian packaging scheme to support only one version of
xerces 3.x in the archive at a time. This is a different conclusion
from the one I think you've indicated, so I'll explain my reasoning.
Read on if you're interested, but don't feel like you need to spend
more time on this.
It is the general practice within debian not to have multiple
source-compatible versions of a library in the archive at a time.
When a source-compatible but binary-incompatible release of a package
is made, the source and development package names stay the same, but
the package containing the runtime libraries gets renamed, and we
force a "library transition" in which all depending packages must be
recompiled. As long as we keep the development package name the same,
this is little or no work for package maintainers as the release team
can automatically trigger such recompilations. Packages in transition
become temporarily uninstallable in the unstable distribution, but
they remain working on existing systems since the old and new runtime
library packages can coexist.
Ordinarily, I would just handle xerces-c this way without even asking,
as I have done with all my other packages. The only reason I bring up
the question at all is that, in the past, it has not always been the
case that subsequent minor releases are source compatible. At least,
this is the case with XML::Xerces (a.k.a. xerces-p, or debian package
libxml-xerces-perl) which depends on a specific minor version of
xerces-c. If I go to my strongly preferred policy of supporting only
one source-compatible version at a time, then packages that work with
one version but not with a subsequent minor release of the same
version will get left behind. If the only such package is
libxml-xerces-perl, then I don't think I'll keep multiple
source-compatible versions around just for it. If it's reasonable to
expect other packages to have the same issue, I may then want to stick
with the current policy. I'll also ask on
debian-devel@lists.debian.org.
The reason I'm not so worried about libxml-xerces-perl is that,
according to popcon (debian's "popularity contest", which counts users
of packages on systems that voluntarily participate), only 0.03% of
debian systems actively use libxml-xerces-perl. This is 18 systems
among those who use popcon. Although I hate to see a package dropped
from the archive, I'm not sure libxml-xerces-perl is enough of a
reason to incur the overhead of maintaining multiple simultaneous
source-compatible versions of xerces-c in debian. There is also a bug
reported against it that it fails to build with perl 5.10, though
there seems to be a fix for this floating around -- I haven't really
investigated yet.
>> 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.
There has to be a separate -dev package for each source package,
though it's okay if libxerces-c-dev belongs to the most recent one and
older ones, if any, have a numbered libxerces-cnn-dev package. This
is how the Berkeley DB packages are managed. The debian packaging
system allows conflicts to be named, and that's the mechanism by which
people are prevented from having both versions installed at the same
time.
--Jay
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Boris Kolpackov <bo...@codesynthesis.com>.
Hi Jay,
Jay Berkenbilt <ej...@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
Re: Xerces-C++ 3.0.0 beta 1 released
Posted by Jay Berkenbilt <ej...@ql.org>.
Boris Kolpackov <bo...@codesynthesis.com> 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 <ej...@ql.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org