File: README

package info (click to toggle)
sp-gxmlcpp 1.0.20040603-1
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 1,592 kB
  • ctags: 267
  • sloc: sh: 7,360; cpp: 1,626; makefile: 120
file content (59 lines) | stat: -rw-r--r-- 2,197 bytes parent folder | download | duplicates (6)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
This is the Schlund+Partner C++ wrapper for libxml. See INSTALL
and INSTALL.sp-gxmlcpp for installation instructions.

Questions and comments to sp-gxmlcpp@oss.schlund.de

Drawbacks and known bugs of this wrapper
----------------------------------------

* Serialization (XMLDump) is hardcoded to produce UTF-8 encoding.
* There are some slight design flaws.
* XMLNode* classes are not tested properly ;)
* There is no clear exception handling concept.

Package Versioning Scheme
-------------------------

SPRelease automates the release prodedure in this package. ChangeLog
is produced automatically from CVS Logs.

VERSION="MAJOR.MINOR.DATE" with

MAJOR: Substantial changes (the "Project Office Satisfication Number").
MINOR: Odd numbers development versions, even numbers "stable" versions.
       Each time we postulate some release "stable", this number is increased
       by one (from odd to even), CVS is tagged, then increased again
       by one (from even to odd). Changes (and subsequent Patchlevel releases)
       to that stable version might be done later in a seperate branch (if
       needed).
DATE : Date in the form YYYYMMDD. Patchlevel releases.


Library Versioning Scheme
-------------------------

 This package uses "libtool" to create all libraries, and adopts the
"Libtool Versioning System" for shared libraries. Please see in
libtool's documentation.

 Main library versions and package versions relate to each other this
way:

Name                 Package Version    Library Main Version
1st unstable branch  0.1.*              0
1st stable branch    1.0.*              1
2nd unstable branch  1.1.*              2
2nd stable branch    1.2.*              3
...

 This way, odd library main versions denote stable versions; this is
simple and effective.

 As little drawback, we are not able to reflect interface incompatible
changes _inside_ an unstable branch by means of so-library
versioning. So if you do not relink, odd things might happen -- but
hey, it's unstable ;).

 At the same time, we are not able to reflect interface incompatible
changes _inside_ a stable branch -- but this is a feature, as the
interface _must_ not change thusly in a stable branch.